Комментарии 40
Как-то не заметил в статье упоминания открытых протоколов и стандартов.
Ну и да, говорить о устойчивости сети при сбое коммутатора, и тут же говорить об stp - это сильно. Я бы еще понял mstp (хотя его настройка - это тот еще адок, не говоря уже о поддержке в актуальном состоянии).
хватит этой дремучей древности.
Сеть строится не на ieee802.3, а на rfc1180/rfc2460, потому что в сети присутствуют не только коммутаторы, но и такие штуки как балансировщики нагрузки, прокси-серверы и прочие системы обнаружения вторжений и waf-ы. А им наплевать на ethernet, им подавай ip/ipv6.
В стеке свитчей первый порт тоже будет gi1/0/1, если заранее позаботиться о приоритете коммутаторов в стеке. 99% бестолковых интеграторов этого не делают.
Перестаньте строить L2-топологии с STP. Связь между core/distrib и остальными слоями нужно сделать маршрутизируемой. Если уж вы объеденили порты коммутаторов в LAG-и, не надо делать много lag-ов и один из них заблокироует stp - сделайте один большой толстый m-lag. К слову, а вы знаете как бысто LACP выведет линк из балансировки, если связь упадет, но электрически порт будет up? такое бывает...
Перестаньте отделять wifi от остальной кампусной сети. Это точно такое же подключение пользователей. И не надо петь про безопасность и перехват пакетов в воздухе - 802.1x, шифрование и нормальная аутентификация решат все проблемы.
И наконец - начните использовать современные технологии, хотя вы в популистских статьях. stp/lag/стеки коммутаторов - вы как из 19го века выползли. Где lisp, Cisco SD-Access или Huawei Agile Campus?
"Перестаньте строить L2-топологии с STP" - хорошо, а как быть, если например один из коммутаторов ядра сломается физически и производитель больше их не поставляет в страну? В случае использования L2 топологии и открытых стандартов, сможем заказать любой другой коммутатор ядра любого вендора и заменить с минимально возможным простоем сервиса. Это не так красиво, но технически возможно.
"Перестаньте отделять wifi от остальной кампусной сети" - беспроводные сети, это отдельный раздел, про это еще будет позже, в одной статье обо всем не написать, давайте идти по-порядку.
"вы как из 19го века выползли" - совершенно верно, суть идеологии отказаться от красивых и навязчивых проприетарных решений, а вернуться в 21 век нам поможет автоматизация и подход Network as a Code
В ядре нет коммутаторов, там только маршрутизаторы. Если у вас L2 ходит через ядро, то у вас .. как бы сказать, ядро нестабильное. С периодом полураспада.
с каких пор l2 или l3 зависят от производителя? ospf и ip - открытые стандарты
Стекирование, кластеризация и прочая виртуализация достигаются за счет использования проприетарных решений, которые позволяют сделать loop free Layer 2 домен (например Cisco VSS, vPC, Avaya L2 фабрика на базе IS-IS), или же построить правила межсетевого экрана на основании тегов (например Cisco Security Group Tag). Все это очень удобно, но есть и ряд недостатков, которые описаны в обсуждаемой статье.
А зачем там такой гигантский L2 домен? Почему нельзя вынести резервирование на L3?
Все просто: если отдел бухгалтерии разбредется по разным зданиям и этажам, а нам надо их держать в одном VLAN, то перенос L3 на уровень распределения существенно все усложнит.
зачем сотрудников одного отдела держать в одном vlan-е? только не говорите "доступы". Доступы управляются не на коммутаторах, и не на основе ip-адресов.
Идеология не использовать dACL, минимизировать зависимость от производителя. А помимо ПК, может быть много других устройств, не умеющих 802.1х. Это не рецепт для конкретной реализации, а концепция, которую можно масштабировать и применять в большинстве случаев. А управление правилами межсетевого экрана с интеграцией с AD будет работать только на части устройств.
а как на ваш взгляд в сети происходит управление доступами если не на основе ip-адресов?
Основные правила на межсетевом экране разрабатываются на основе IP подсетей, которым сопоставляются VLAN-ы. Правила на основе конкретного IP, учетной записи в AD или FQDN - более частные случаи, не везде подходят и не всегда упрощают систему.
спасибо, я разделяю ваше мнение, но я собственно ожидаю комментария Karroplan, он похоже знает какой то способ управления доступами в сети основанный не на IP адресах и мне очень интересно его узнать.
Я думаю что наш коллега имел ввиду то что современные решения позволяют разбить сеть на L3, полностью уйти от L2 и там не важно в каком VLAN окажется host, а правила межсетевого экрана будет применяться на основании данных, такие как учетная запись в AD, результат профилирования устройства к определенному типу и пр. Конечно, сами межсетевые экраны будут реализовывать правила по IP, но это уже "под капотом".
вы не поверите, но правила можно писать на основе учетных записей Active Directory, групп Active Directory. Погуглите - firewall identity awareness. Любой уважающий себя вендор это внедрил лет 10-15 назад. Ну или на основе сервисных меток, которые назначаются тоже на основе аутентификации/идентификации (Cisco SGT, например). В таком случае и пользователь может либо между рабочими станциями пересаживаться - куда пришел, туда и сел, либо ходить с ноутом по этажам и включаться то проводом, то беспроводом. Мобилити.
https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id
А можете подсказать вендоров производящих межсетевые экраны у которых достаточно надёжно и качественно работают правила на основе учетных записей Active Directory, в частности не возникает никаких проблем с терминальными серверами, UPN суффиксами, пользователями которые проходят процедуру входа в сеистему в лучшем случае 1 раз в месяц?
писать правила на основе ip-адресов имеет смысл только для сущностей с фиксированными адресами - bare-metal сервера, специальные appliance типа реверс-прокси или балансировщиков. Нет никакого смысла это делать для пользователей, чтоб прибивать пользовательские адреса гвоздями либо на машине либо в резервациях dhcp и потом самим разгребать эти Авгиевы конюшни. Даже для виртуальных машин правила на основе адресов могут ограничивать гибкость.
А почему нельзя каждого пользователя держать в отдельном L2-домене? В идеале, в канале должен быть только пользователь и его шлюз.
хм.... а как это сделать для 4097 пользователей?
Откуда в 2021 году (да и лет 10 назад) "горизонтальный" traffic возьмётся? Он и 20-то лет назад был в основном в виде печати на принтере, подключенному к компьютеру коллеги.
Вы упомянули некий case, который, если я правильно понял ваше предложение
хорошо, если трафик ходит «по вертикали», как у операторов, если же много «горизонтального» трафика, то
является не только распространённым, но и чуть ли не стандартным на предприятиях(?), в отличии от операторских сетей. Если не сложно, опишите, пожалуйста, подробнее, для чего в таких case-ах нужен «горизонтальный» traffic?
Впрочем, обоснованием выбранного проектного решения должен бы автор заниматься, а не каментаторы )
Я бы предложил завернуть весь traffic в VPN, всё равно всё к хотя бы частичному work from home движется. Куча проблем сразу снимается.
Для 4097 пользователей вам потребуется 4097 /31 (/30, если вам старые ос поддерживать) сетей, плюс ощутимый флуд в BGP. Повторю, каждый пользователь в своём L2, внутри которого только сам пользователь и его шлюз. Дальше там чистой воды маршрутизация, а вот как динамически отмаршрутизировать несколько тысяч сетей... В full view с 600к+ справляются и ничего.
Можно сэкономить ресурсы, объединив на интерфейсе ближайшего маршрутизатора эти /30. То есть со стороны маршрутизатора есть только интерфейс /24 или даже больше. Оконечные устройства получают от DHCP-сервера /30 без default gateway, но с on-link static route(s) на маршрутизатор(ы): один и тот же адрес маршрутизатора для всех - он лежит вне их /30 сетей, но, поскольку маршрут on-link, это работает. На уровне L2 дополнительную изоляцию может обеспечить, например, PVLAN.
Экономия на спичках, а в замен вы получаете общий L2 со всем шлаком. L3-fabric с маршрутизацией - это единственный разумный метод ограничения.
Я отвечал не про pvlan, а про идею экономить на IP. Делаете нормальный шлюз каждому, без проприетарных технологий. Пришёл человек, оказался в своём l2 сегменте, в котором есть только он, и роутер. Для этого не нужно трафик клиента куда-то "заворачивать" и тащить на "спайн". Достаточно поднять на access-устройстве (куда клиент воткнут или подключился) L3 интерфейс и настроить BGP.
Сейчас мне расскажут как невероятно дорого и расточительно разбазаривать L3-порты в 2021. А я в это не поверю.
Вынос L3 на уровень доступа в классической парадигме сети проблематичен с точки зрения безопасности — либо все wiring closets и каналы связи с ними необходимо охранять, либо мы не можем доверять IP-адресу устройства, кто-то другой может через BGP его перехватить. И я не говорю о «зашитой» аутентификации по фиксированному IP — сессию аутентификации (хоть через вход в AD, хоть как угодно ещё) можно либо привязать к IP, которому мы уже не можем доверять, либо необходимо подписывать/шифровать весь traffic тем же IPSEC, например.
В итоге я в последнее время вижу перспективу в переходе на повальный VPN до рабочего места. Сегодня работник подключился к L3+BGP коммутатору доступа, а завтра он всё равно подключится к своему домашнему WiFi или даже из кафе/парка и т.д. Зачем нам две инфраструктуры? Весь лишний L2-traffic отсекается персональным брандмауэром на клиентском устройстве, резко снижаются требования к сетевой инфраструктуре — лишь бы пакеты доходили. Scope доверия/безопасности сужается до VPN-инфраструктуры и узлов контроля потоков.
А, я только сейчас осознал бездну старинного LAN'а, где 192.168.х.з почему-то более доверен, чем 104.103.102.101. Разумеется, трафик в локальной сети не является доверенным для серверов. Я не знаю что там думает по этому поводу AD, но современные рабочие места уже давно не имеют понимания о "локальной сети". Есть авторизация? Пользуешься. Нет - прости, 403. ACL'ки на сетевом уровне всего лишь добавляют защиты от условных CVE-RCE, но не являются методом построения сети.
Более того, понятия "периметра" для защиты уже давно не существует, потому что даже в самом жирном энтерпрайзе так или иначе внешние сервисы в рабочий процесс встроены (от электронной отсылки в налоговую до github'а).
Я говорил всего лишь про банальный уровень изоляции клиентов от хлама (меньше шума в L2, меньше просыпаться мобильным устройствам).
Там же, где нечего защищать (по факту решений, принимаемых бизнесом, вслух так почти никто, понятное дело, не скажет) и в малом бизнесе — да: Office 365, *ify и *lr. Но зачем в организации, где нет потребности в своей сети, её вообще строить? Если нужен просто интернет, то абсолютно не важно, есть L2 traffic, нет L2 traffic-а, есть проводная связь или упала и переключились на WiFi или на сотовый.
Собственно, и моё предложение по переходу к VPN до рабочего места позволяет точно так же расслабиться и резко уменьшить требования к инфраструктуре LAN при этом не выставляя во всеобщий доступ тысячи внутренних ресурсов, каждый из которых и все в совокупности иначе нужно защищать по высшему разряду.
Отказаться от контроля потоков данных можно, очень многие предприятия так и сделали, точнее никогда этого контроля и не имели (сужу по ситуации в Северной Америке). На случай CVE/RCE, как вы говорите, страховые компании предоставляют им страховки от хэкеров. Куда это приведёт — сложно сказать. Может быть, все привыкнут, что сегодня нет бензина, а на следующей неделе не завезут во все магазины мяса. А может наоборот народ начнёт-таки отворачиваться от таких компаний и индустрия вынуждено придёт к неким минимальным требованиями по типу PCI DSS и за пределами сферы работы с кредитными картами — время покажет.
Я работаю в предприятии непрерывного цикла с мощностями на куче континентов. И мне дико читать про защиту сети с помощью L2 сегментов. Если вы хотите закрыть от внешнего мира что-то, то вы можете организовать произвольное количество несвязных сетей, не закладываясь на L2. VRF, network namespaces, airgap, whatever.
Собственно, одна из услуг, которую мы предлагаем - это приватная сеть. Честный, настоящий трансконтинентальный L3.
И я не понимаю почему кто-то до сих пор в серьёз считает, что изоляция на уровне L2 - это хорошо.
Партиционирование сетей никаким образом на L2 не должно быть завязано. L2 - это надстройка над физикой, чтобы поддерживать работу L3. Если бизнес-решения выносятся на L2, то это печально. Раньше это нужно было делать по бедности (bgp на access - это дооорого), то сейчас-то...
Есть общие для всех подходы, а есть технические средства их реализации. Если говорить о конкретных технологиях, то есть смысл обсуждать их предметно, а не на уровне «мне дико».
Управление потоками в парадигме микросегментации, конечно же, осуществляется на уровне (реально) L3, а виртуально — вообще L7. Как конкретно изолированный поток (опять же, мы говорим разными словами об одном и том же — в вашей терминологии это "L2 на клиента") дойдёт до точки применения policies, и где эта точка вообще будет — в локальном ли или глобальном ядре, прямо на доступе или вообще это всё в SDN внутри системы виртуализации происходить будет — вопрос технологий на конкретном предприятии.
Если проще в конкретной ситуации довести в изолированном L2-сегменте поток до ядра, и применять к нему L3/L7 policies в ядре, то я не вижу, в чём тут глобальная проблема — какая разница сколько интерфейсов и L3 hop-ов задействовано по дороге — 1 или 100k, лишь бы не было возможности воздействовать на чужой traffic и выполнялись требования к надёжности. Если есть какие-то предметные возражения, давайте обсудим, мне действительно интересно послушать ваши аргументы. Опять же, если на каком-то предприятии уже стандартизован подход, например, "BGP на доступе", то, конечно, нужно ему и следовать по возможности.
С точки зрения безопасности мне, всё же, в идеи расширения BGP до доступа видится вектор нетривиальной, но вполне осуществимой целенаправленной атаки в условиях проникновения третьих лиц в network closet с оборудованием, на котором бегает BGP. Предотвратить такое не всегда возможно, если мы не говорим, опять же, исключительно об защищённых DC, хотя даже в DC я бы не зарекался — буквально вчера коллеге в супер-защищённом DC охрана предложила самому им сказать, от какого конкретно шкафа ему выдать ключи, не в смысле проверки, знает ли он, а они готовы были ему поверить на слово.
Так вот, я вполне представляю захват контроля над оборудованием доступа, а, возможно, достаточно будет и доступа к каналу связи. После чего можно анонсировать атакуемую подсеть (и если BGP общий, то хоть с другого континента) и получать её traffic. Казалось бы, traffic-то всё равно зашифрован. Но если нет контроля сетевых потоков, то, теоретически, можно получать traffic предназначенный для атакуемой цели, приходящий из Internet. Далее, как пример, производится ACME-запрос от имени цели на получение Let's Encrypt сертификата. Там много не надо — достаточно иметь возможность ответить по HTTP или DNS. И вот уже поддельный сервер может полностью подменить собой настоящий, отвечать по HTTPS. Да, и на этот случай есть способы mitigation: certificate pinning, RFC 8659 и т.д. Но это означает, что выбрав некую технологию для решения своей задачи, мы на ровном месте повысили требования при решении других задач. Вместо того, чтобы обеспечить ещё один уровень защиты, мы, наоборот, «переложили с больной головы на здоровую».
Ещё нюанс — расширяя scope безопасности / attack surface, мы получаем дополнительные вопросы от аудиторов. Некоторые аудиторы вообще к недетерминированным компонентам, таким как любой протокол динамической маршрутизации относятся со скептицизмом. Если бизнес-требования не включают такую гибкость, то возникает резонный вопрос, зачем, скажем, в банке иметь возможность на порту в филиале в мелком городке объявить в BGP наличие тут веб-сервера банка с другого континента. Даже не с точки зрения какие mitigations & compensating controls вы применяете, а просто — зачем? И ответ «архитектору так захотелось / так проще управлять» может быть и не принят.
Вы слишком фокусируетесь на "дата-центре". У нас есть бэкофис, и он мало отличается от большинства бэк-офисов мира (кроме того, что у нас винда запрещена к использованию корпоративной security policy). И когда случился ковид и локдаун, нам сказали "обеды отменяются, работаем из дома", и ничего не поменялось.
Это пример современной компании, которой к локдауну не пришлось делать практически ничего (кроме family support в форме игрушек/паззлов и обедов для того, чтобы занять детей и разгрузить родителей).
Алсо, атака на BGP делается куда проще без взламывания шкафов, тот же анонс можно послать через 100500 транзитных AS, которые ещё не фильтруют.
Ничего не мешает на каждом коммутаторе агрегации держать одинаковые маршрутизируемые vlan + svi acl с индивидуальной IP подсетью. Шаблоны настройки устройств доступа при этом останутся неизменными для всей сети.
3 уровневая сеть с stp - это большая ошибка и потенциальная проблема.
Clos network нужно строить в 2021-м
Вопросы построения сети. Проприетарное рабство, отказоустойчивость и модульность (часть 1)