Pull to refresh

Comments 12

Спасибо большое! Никогда не знаешь, когда пригодится. Определённо в «закладки»
вы саб интерфейсы в влан не посадили.
пример:

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, но как это может мешать работе моста?).
в качестве коммента:
такую схему нельзя применять в условиях жестких требований:
1) к отказоустойчивости. Т.к. свитч на котором живет куча виланов становится единой точкой отказа. Умер свитч — умерло всё.
2) к безопасности. Особенно вторая схема, где и фаерволл-он-стик и роутер-он-стик. Потому как опять же данные из разных доменов безопасности проходят через одну и ту же железку. Трафик из пользовательских сетей в дмз идет через тот же свитч что и трафик из интернета. Достаточно подвергнуть свитч несложной атаке на переполнение fib/cam и вуаля…
Могу прокомментировать по первому случаю. Именно для этого я написал об использовании модульного коммутатора с двумя блоками питания и двумя супервизорами и возможно даже резервной линейной платой. С такой системой отказоустойчивости, шансы отказа коммутатора ничтожно малы, настолько, что это практически не реально, а если использовать два таких коммутатора, объединенных по технологии VSS, тогда скорее метеорит упадет, чем что-то откажет.

А вот по безопасности интересно, я бы почитал об этом подробнее.
Сейчас поразмыслил по поводу безопасности. Атаку на cam таблицу коммутатора можно реализовать только будучи в одном бродкастовом домене с коммутатором, по сути злоумышленник должен каким-то образом оказаться в том же VLAN, который проброшен, например, от коммутатора до маршрутизатора. А как он это может сделать? Только физически притащить свое оборудование и поставить его на участке подключения между коммутатором и провайдером. Это кажется уже фантастикой.

В любом случае можно защититься от такой атаки средствами port-security.

На счет переполнения FIB, на коммутаторе на данном VLAN отсутствуют IP адреса, а следовательно не выполняется маршрутизация, отсюда о FIB можно не беспокоиться, т.к. FIB попросту не будет работать.
Где можно подробнее прочитать про подобную атаку на свитч?
«стандартный» пример — VPN-концентратор с одним сетевым линком
Sign up to leave a comment.

Articles

Change theme settings