Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: Пред. 1 2 3 4 След.
RSS
Фильтры грубой и тонкой очистки трафика
 
Цитата
А по поводу MPLS - можно ссылку про то где и как используется сеть 5/8? Я никогда не слышал про то, что MPLS пользуется этоми адресами. Google похоже тоже...
На cisco посмотри. MPLS это не он, а она. Сетевая технология Multi Plexing Layer Switch. Встретить можешь к примеру если у тебя есть ATM оборудование, например роутер с Wan картой, если ты сделаешь трасерт на ip которого, нет в той подсети получишь ответ от друго маршрутизатора, обычно адресс 5.5.5.4 ;)))
 
switching )))))
 
Цитата
_liqud пишет:
На cisco посмотри. MPLS это не он, а она. Сетевая технология Multi Plexing Layer Switch. Встретить можешь к примеру если у тебя есть ATM оборудование, например роутер с Wan картой, если ты сделаешь трасерт на ip которого, нет в той подсети получишь ответ от друго маршрутизатора, обычно адресс 5.5.5.4 ;)))
Cтоп. Во первых Multiprotocol Label Switching - я посещал курс MLSTE на досуге [IMG]http://www.securitylab.ru/forum/smileys/smiley2.gif[/IMG] Во вторых ты все-таки напутал про сеть 5/8. (Если хочешь исправить свой текст - то у нас в конфе есть кнопка ПРАВИТЬ. [IMG]http://www.securitylab.ru/forum/smileys/smiley2.gif[/IMG])
Вообще, ты загрузил по поводу он и она :) Switching это наверно все таки ОН :)
 
Цитата
ksiva пишет:
Вообще, ты загрузил по поводу он и она :) Switching это наверно все таки ОН :)

К слову switching вообще нельзя применить он и она. Это некое действие, растянутое во времени.
 
да... точно.... switching это наверно скорее герундий, чем отглагольное существительное  [IMG]http://www.securitylab.ru/forum/smileys/smiley17.gif[/IMG]
 
Отличная статья, побольше бы таких..[IMG]http://www.securitylab.ru/forum/smileys/smiley32.gif[/IMG] Сфера информационной безопасности процветает, что не может не радовать! [IMG]http://www.securitylab.ru/forum/smileys/smiley4.gif[/IMG]
 
Цитата
^rage^ пишет:
при всём уважении к автору повторю фразу "ничего нового". лучше бы отжать воду и сделать howto.
Там скука, там обман иль бред;
В том совести, в том смысла нет;
На всех различные вериги;
И устарела старина,
И старым бредит новизна.
[IMG]http://www.securitylab.ru/forum/smileys/smiley1.gif[/IMG]
 
Полностью согласен с Nomadом, хотя:
1. Маршрутизатор, теоретически, может заниматься arp-спуфингом и отвечать своим mac-ом на все arp-запросы, но это не из за того, что хост 2 не ответил на arp-запрос и хост 1 кинет пакет на дефаултовый шлюз. (такого не будет никогда).
2. В стандартной настройке (не знаю, правда, можно ли это изменить), если на интерфейс маршрутизатора придет пакет с IP источника и получателя, находящихся в той же подсети, что и маршрутизатор, но не являющегося ip-адресом интерфейса маршрутизатора, последний пошлет пакет "redirection" на адрес источника с правильными настройками подсети (маска, шлюз) и сообщением типа "ты чё делаешь-то" и НЕ ПОШЛЕТ ПАКЕТ ПОЛУЧАТЕЛЮ!!!
 
Автору (не в обиду) советую еще раз советую прочитать про маршрутизацию и коммутацию (определения, чем отличаются), а также внимательно прочитать про протоколы ARP, SNMP, ICMP.
 
Цитата
Rossava пишет:
(не знаю, правда, можно ли это изменить) ... последний пошлет пакет "redirection" на адрес источника с правильными настройками подсети
В Linux маршрутизаторе (про Cisco IOS не знаю) делается элементарно:

echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects
 
2 Nomad:
Спасибо за лекбез, буду знать, но я имел ввиду именно киску.
 
Цитата
Rossava пишет:
2. В стандартной настройке (не знаю, правда, можно ли это изменить), если на интерфейс маршрутизатора придет пакет с IP источника и получателя, находящихся в той же подсети, что и маршрутизатор, но не являющегося ip-адресом интерфейса маршрутизатора, последний пошлет пакет "redirection" на адрес источника с правильными настройками подсети (маска, шлюз) и сообщением типа "ты чё делаешь-то" и НЕ ПОШЛЕТ ПАКЕТ ПОЛУЧАТЕЛЮ!!!
так получается, что тогда с изолированного порта на другой изолированный порт ничего нельзя послать вообще через маршрутизатор? это не есть хорошо. иногда это нужно
 
Нда, уж..
Статья, всместо того, что бы разъяснить функционирование и применение достаточно старых технологий super-VLAN и Proxy ARP, вснесла полную сумятицу в головы.
Цитата
Hide пишет:

так получается, что тогда с изолированного порта на другой изолированный порт ничего нельзя послать вообще через маршрутизатор?
2 Hide
Что есть "изолированный" порт для МАРШРУТИЗАТОРА, а что есть - "неизолированный"?! О чем, вообще, речь-то идет?
 
Цитата
Rossava пишет:
Полностью согласен с Nomadом, хотя:
1. Маршрутизатор, теоретически, может заниматься arp-спуфингом и отвечать своим mac-ом на все arp-запросы, но это не из за того, что хост 2 не ответил на arp-запрос и хост 1 кинет пакет на дефаултовый шлюз. (такого не будет никогда).
2. В стандартной настройке (не знаю, правда, можно ли это изменить), если на интерфейс маршрутизатора придет пакет с IP источника и получателя, находящихся в той же подсети, что и маршрутизатор, но не являющегося ip-адресом интерфейса маршрутизатора, последний пошлет пакет "redirection" на адрес источника с правильными настройками подсети (маска, шлюз) и сообщением типа "ты чё делаешь-то" и НЕ ПОШЛЕТ ПАКЕТ ПОЛУЧАТЕЛЮ!!!

Смотрите на этот пакет:
SRC MAC адрес: Хост 1
DST MAC адрес: Маршрутизатор
SRC IP  адрес: Хост 1
DST IP  адрес: Хост 2

Посылаем его в Ethernet сеть.

Почему маршрутизатор должен слать ICMP редиректы? Этот пакет будет доставлен в лучшем виде.

Попробуйте сами. Как частный случай возьмите Хост1==Хост2. В <a href=http://www.tamos.com/download/main/ target="_blank">CommView 5.0</a> как раз добавлен генератор пакетов. Я только что попробовал - все работает.
 
Цитата
Nomad пишет:

Что есть "изолированный" порт для МАРШРУТИЗАТОРА, а что есть - "неизолированный"?! О чем, вообще, речь-то идет?
наверно имеется в виду изолированный порт СВИТЧА.
<a href=http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008007e717.html target="_blank"> http://www.cisco.com/en/US/products/hw/switches/ps708/produc ts_configuration_guide_chapter09186a008007e717.html </a>
 
Цитата
ksiva пишет:

SRC MAC адрес: Хост 1
DST MAC адрес: Маршрутизатор
SRC IP  адрес: Хост 1
DST IP  адрес: Хост 2

Посылаем его в Ethernet сеть.

Почему маршрутизатор должен слать ICMP редиректы? Этот пакет будет доставлен в лучшем виде.

Все так и будет, но с оговорками: очевидно, что таблицы маршрутизации у Х1 и маршрутизатора разные и, плюс к этому, Х2 находится в другом сегменте (на другом интерфейсе), нежели откуда пришел такой пакет. В противном случае - ICMP редирект.

А главный вопрос так и остался открытым - как Х1 сформирует пакет с
DST MAC адрес: Маршрутизатор
DST IP  адрес: Хост 2
(ARP спуфинг - Proxy ARP - PVLAN, вот эту тему можно было бы раскрыть подробнее и понятнее)
 
предполагалось что пакеты от X1 и X2 приходят на один и тот же интерфейс FW(маршрутизатора). Схема была приведена в статье. А раскрыть поподробнее - согласен... надо.. Но уже в другой статье..  В этой статье акцент был сделан, как вы заметили выше, на то КАК РАЗДЕЛИТЬ компьютеры, а не как соединить их, когда они уже разделены PVLAN.

вообще я заметил, что текст писать одному плохо - нужны именно такие критические замечания от кого-либо, например от редактора статьи, чтобы получилось хорошо. Но в данном конкурсе редактор не полагался...
 
С Новым Годом!

Цитата
ksiva пишет:
А раскрыть поподробнее - согласен... надо.. Но уже в другой статье..
Ждем :-))

Лично для меня так и осталась непонятой ситуация: как Х1 узнает, что Х2 недоступен, в случае, когда последний действительно выключен?
Произойдет это на 2-м уровне (ARP replay таймаут) или FW с PVLAN в любом случае ответит своим МАС, а уж затем, убедившись, что Х2 не отвечает, сгенерирует ICMP Destination Unreacheble (3-й уровень). Или как?
 
спасибо.   [IMG]http://www.securitylab.ru/forum/0[/IMG]   С Новым Годом!

я думаю, что на 3-ем уровне все-таки уйдет SYN пакет, а дальше произойдет все то что делает маршрутизатор когда нет хоста в приконнекченой сети. Точнее все будет зависеть от его настроек. если unreachable сообщения запрещены (что как правило так и есть для защиты от DOS атак) - то таймаут.
 
Цитата
ksiva пишет:
.. если unreachable сообщения запрещены (что как правило так и есть для защиты от DOS атак) - то таймаут.

Т.е., если Х2 - DNS сервер и он упал, то Х1 "попадает" на UDP таймауты. Кошмар!
Мне кажется, что ICMP Destination Unreacheble для внутренних интерфейсов запрещать, все же, не стоит.
Страницы: Пред. 1 2 3 4 След.
Читают тему