Комментарии 12
Спасибо большое! Никогда не знаешь, когда пригодится. Определённо в «закладки»
Да, действительно полезно, спасибо!
вы саб интерфейсы в влан не посадили.
пример:
p.s. коммутатора l3 не обязательно применять.
и кому интересно почитайте, 3650-x 3750-x stack power
пример:
telecombook_ru#conf t
telecombook_ru(config)#interface Gi0/0.50
telecombook_ru(config-if)#enca do 50
telecombook_ru(config-if)#ip address 192.168.1.254 255.255.255.0
telecombook_ru(config-if)#ip nat inside
p.s. коммутатора l3 не обязательно применять.
и кому интересно почитайте, 3650-x 3750-x stack power
«Router-on-a-Stick» иногда называют «lollipop» — «леденец на палочке» :)
Недавно настроил именно такую схему дома. D-Link DIR-825 плюс прошивка OpenWRT (родная прошивка не поддерживает VLan-ы). Два провайдера, основная локалка, гостевая локалка и гостевой WiFi — все в отдельных vlan-ах, все имеют доступ только к моему роутеру (на котором Hardened Gentoo Linux), а он уже решает кого куда пущать или не пущать.
При кажущейся простоте настройки было несколько странных проблем. Например, встроенная ssh отзывалась на IP 192.168.x.x, но не отзывалась на 10.x.x.x — при этом судя по netstat она висела на 0.0.0.0:22 и не была привязана ни к какому интерфейсу. Другая похожая проблема — WAN интерфейс почему-то отказывался работать в мосте (bridge) с VLAN1, но работал нормально с любым другим номером VLAN (я в курсе про PVLAN, который как раз равен 1, но как это может мешать работе моста?).
При кажущейся простоте настройки было несколько странных проблем. Например, встроенная ssh отзывалась на IP 192.168.x.x, но не отзывалась на 10.x.x.x — при этом судя по netstat она висела на 0.0.0.0:22 и не была привязана ни к какому интерфейсу. Другая похожая проблема — WAN интерфейс почему-то отказывался работать в мосте (bridge) с VLAN1, но работал нормально с любым другим номером VLAN (я в курсе про PVLAN, который как раз равен 1, но как это может мешать работе моста?).
в качестве коммента:
такую схему нельзя применять в условиях жестких требований:
1) к отказоустойчивости. Т.к. свитч на котором живет куча виланов становится единой точкой отказа. Умер свитч — умерло всё.
2) к безопасности. Особенно вторая схема, где и фаерволл-он-стик и роутер-он-стик. Потому как опять же данные из разных доменов безопасности проходят через одну и ту же железку. Трафик из пользовательских сетей в дмз идет через тот же свитч что и трафик из интернета. Достаточно подвергнуть свитч несложной атаке на переполнение fib/cam и вуаля…
такую схему нельзя применять в условиях жестких требований:
1) к отказоустойчивости. Т.к. свитч на котором живет куча виланов становится единой точкой отказа. Умер свитч — умерло всё.
2) к безопасности. Особенно вторая схема, где и фаерволл-он-стик и роутер-он-стик. Потому как опять же данные из разных доменов безопасности проходят через одну и ту же железку. Трафик из пользовательских сетей в дмз идет через тот же свитч что и трафик из интернета. Достаточно подвергнуть свитч несложной атаке на переполнение fib/cam и вуаля…
Могу прокомментировать по первому случаю. Именно для этого я написал об использовании модульного коммутатора с двумя блоками питания и двумя супервизорами и возможно даже резервной линейной платой. С такой системой отказоустойчивости, шансы отказа коммутатора ничтожно малы, настолько, что это практически не реально, а если использовать два таких коммутатора, объединенных по технологии VSS, тогда скорее метеорит упадет, чем что-то откажет.
А вот по безопасности интересно, я бы почитал об этом подробнее.
А вот по безопасности интересно, я бы почитал об этом подробнее.
Сейчас поразмыслил по поводу безопасности. Атаку на cam таблицу коммутатора можно реализовать только будучи в одном бродкастовом домене с коммутатором, по сути злоумышленник должен каким-то образом оказаться в том же VLAN, который проброшен, например, от коммутатора до маршрутизатора. А как он это может сделать? Только физически притащить свое оборудование и поставить его на участке подключения между коммутатором и провайдером. Это кажется уже фантастикой.
В любом случае можно защититься от такой атаки средствами port-security.
На счет переполнения FIB, на коммутаторе на данном VLAN отсутствуют IP адреса, а следовательно не выполняется маршрутизация, отсюда о FIB можно не беспокоиться, т.к. FIB попросту не будет работать.
В любом случае можно защититься от такой атаки средствами port-security.
На счет переполнения FIB, на коммутаторе на данном VLAN отсутствуют IP адреса, а следовательно не выполняется маршрутизация, отсюда о FIB можно не беспокоиться, т.к. FIB попросту не будет работать.
Где можно подробнее прочитать про подобную атаку на свитч?
«стандартный» пример — VPN-концентратор с одним сетевым линком
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура Router-on-a-Stick в сети передачи данных