Когда мы говорим об инфраструктурной сети, важно понимать, что это не просто сеть для сотрудников. Инфраструктурная сеть в Яндексе решает задачу, без которой невозможно функционирование компании: обеспечить связанность сотрудников и сервисов, независимо от того, где они находятся. Сегодня у Яндекса более сотни офисов по всему миру, и в каждом из них нужно обеспечить стабильный доступ к интернету и к внутренним корпоративным ресурсам.
Меня зовут Дмитрий Литовченко, я сетевой инженер группы офисных и инфраструктурных сетей в Yandex Infrastructure. В этой статье я расскажу историю, как эволюционировали отношения нашей инфраструктурной сети и сети дата‑центров: наш полученный опыт за несколько лет, декаплинг сетей, планы развития.
Офис и out-of-band: две стороны одной сети
Под словом «офис» понимается не только классическое рабочее прост��анство с переговорками и кофепойнтами. Склады Яндекс Маркета, технические площадки, точки присутствия и даже дата‑центры — все они включены в общую инфраструктурную сеть для сотрудников. Более того, доступ к ней должны иметь и удалённые сотрудники — для этого используется флот OpenVPN‑концентраторов, который обеспечивает безопасное подключение извне. Подробно об этом рассказывал Борис Лыточкин на конференции Next Hop 2020, где он объяснил, как во время пандемии удалось масштабировать однопоточный OpenVPN до уровня Яндекса.
В дата‑центрах инфраструктурная сеть разделена на два сегмента:
Офисная сеть — для сотрудников, которые физически работают в ЦОДе.
Out‑of‑band (OOB) — сеть для управления оборудованием, где живут консольные доступы, IPMI, менеджмент‑интерфейсы, сетевые порты управления.
Инженер, работающий из офисной сети, в случае проблем должен иметь возможность без лишних костылей достучаться до оборудования в OOB. Сделать это становится проще, когда офисная и out‑of‑band‑сеть строятся одной командой по одинаковым принципам.
Как строилась инфраструктурная сеть Яндекса
Мы рассмотрим эти принципы на трёх примерах. Первый — это офис в центральном регионе, второй — региональный офис, третий — это крупный офис в центральном регионе.
Прямая оптика в офис — плохо масштабируемое решение
Когда Яндекс только начинал развивать офисную инфраструктуру, все офисы находились в Москве. Схема была простой и понятной: от офиса до точки присутствия Яндекса прокладывалась или арендовалась оптика, а офисные edge‑роутеры соединялись с бордерами компании по eBGP. Со стороны Яндекса использовалась публичная автономная система (AS) компании, а со стороны офиса — приватная AS.
Такой подход решал сразу две задачи:
Офисы видели друг друга через внутренний Backbone Яндекса.
Тот же Backbone обеспечивал выход в интернет.
Это решение работало, пока офисы были сосредоточены в Москве, но не масштабировалось при росте инфраструктуры. А Яндекс рос, офисов становилось всё больше. Стало очевидно, что подключение офиса оптикой к точке присутствия — немасштабируемое и трудно воспроизводимое решение.
Переход к VPN-концентраторам
Чтобы упростить и стандартизировать подключение, офисы стали строить IPsec‑туннели до VPN‑концентраторов в магистрали. Внутри туннеля поднимается BGP‑сессия, VPN‑концентратор анонсирует суперсети Яндекса, офис — своё адресное пространство. Для выхода в мир используется простая и масштабируемая услуга от операторов — /29 публичная IPv4-сеть, взятая в каждом офисе у двух провайдеров. С этих адресов строятся IPsec‑туннели до лупбэков VPN‑концентраторов.
В каждом офисе — обязательно минимум два интернет‑провайдера, причём с равной полосой пропускания. Пропускная способность выбирается так, чтобы офис оставался на связи даже при падении всех каналов, кроме одного. Важно, что в этой схеме нет понятия «основного» и «резервного» оператора: трафик в корпоративную сеть идёт через одного, а интернет‑трафик — через другого.
Офис оборудован двумя edge‑роутерами, подключёнными к двум операторам связи. Каждый роутер строит несколько IPsec‑туннелей через каждого из операторов. Все туннели работают по схеме active backup: в конкретный момент активен только один, остальные ждут своего часа. Приоритеты туннелей задаются через абстрактные веса, которые при генерации конфигурации трансформируются в конкретные атрибуты BGP: local preference, MED и так далее.
Чтобы понять, как это работает, можно посмотреть на жизненный цикл таблицы маршрутизации на edge‑роутере. В начальный момент (в «нулевом состоянии») на роутере заданы только статические маршруты — дефолт в сторону провайдеров и хостовые маршруты до лупбэк‑адресов VPN‑концентраторов. Это нужно, чтобы туннели не строились поверх самих себя.
Когда IPsec‑ и BGP‑сессии поднимаются, VPN‑концентратор начинает анонсировать суперсети Яндекса и дефолтный маршрут. Абстрактный вес при этом интерпретируется по‑разному для разных типов анонсов:
вес 1 означает приоритетный маршрут в корпоративную сеть и пониженную приоритетность дефолта;
вес 2 приоритизирует дефолтный маршрут и понижает приоритет для корпоративных сетей.
Кроме того, при импорте дефолта роутер подменяет next hop на адрес провайдера. Это позволяет при низких таймерах быстро снять нагрузку с неисправного канала: если IPsec‑туннель или BGP‑сессия падают, маршрут по умолчанию просто исчезает, а трафик через проблемного провайдера не уходит.
Офисная сеть работает в dual‑stack‑режиме — IPv4 и IPv6. IPv4-трафик в интернет, пройдя через NAT, сразу отправляется в оператора связи, через провайдеров, а IPv6 тянется по IPsec‑туннелю до Backbone, где есть полноценный выход в транзиты.
FreeBSD как универсальный офисный роутер
Когда мы говорим про edge‑роутер, то имеем в виду не отдельную железку в стойке. Это одна из задач, выполняемых офисным роутером, который совмещает несколько функций. На практике это пара серверов под FreeBSD, выполняющих задачи:
маршрутизации — bird;
файрволинга — ipfw;
отказоустойчивости — CARP (вариация на тему VRRP);
аутентификации — FreeRADIUS;
DNS — Unbound.
Таким образом, в качестве ПО используются проверенные опенсорс‑компоненты. Контейнеризация реализована через FreeBSD Jail.
Такой подход даёт два преимущества. Во‑первых, офисные роутеры построены на стандартной x86-платформе, поэтому на них легко разворачивать дополнительные сервисы по мере необходимости. Во‑вторых, все офисные роутеры унифицированы: они имеют одинаковый набор сервисов и конфигураций. Это устраняет централизацию и упрощает масштабирование — каждый офис работает по тем же принципам, что и любой другой.
Отказоустойчивость обеспечивается с помощью CARP — реализации протокола First Hop Redundancy в FreeBSD. Это значит, что L3-граница сети начинается именно на офисных роутерах, а не на свитчах. Коммутационное оборудование работает только на L2.
По мере роста офисов и количества коммутаторов L2-домены начали растягиваться, что прив��дило к типичным проблемам: петлям и сложностям со Spanning Tree. Решением стало внедрение L3-сегментации. В каждую коммутационную устанавливается пара маршрутизаторов на FreeBSD, которые обслуживают свой L3-сегмент.
Теперь каждый офисный роутер со всеми своими сервисами разворачивается буквально «Ctrl + C, Ctrl + V» в каждую коммутационную стойку или этаж. Пользовательские VLAN«ы при этом терминируются локально, в пределах одной коммутационной, и не выходят за её границы.»
Такой подход даёт малый blast radius — сбой в одном сегменте не затрагивает остальные. А ещё независимость от центрального маршрутизатора и простое масштабирование, где добавление нового сегмента — это просто ещё один «мини‑офис».
Связность между офисными роутерами и особенности маршрутизации
Каждый офисный роутер соединён двумя линками с коммутаторами агрегации. На этих коммутаторах выделяется отдельный VLAN, внутри которого роутеры строят между собой внутренние (internal) BGP‑сессии по схеме full mesh.
При таком физическом дизайне использование IGP + iBGP на лупбэках не уменьшит количество сессий — все роутеры и так находятся в одном широковещательном домене, поэтому мы строим iBGP на connected‑интерфейсах. Если в офисе есть оптическое соединение с точкой присутствия, каждый роутер становится полноценным external BGP‑спикером.
Когда BGP стал слишком большим: эволюция магистрали и разделение сетей
Исторически в Яндексе вс�� существовало внутри одной автономной системы — AS13238. Там жило как оборудование дата‑центров в магистрали Яндекса, так и офисные VPN‑концентраторы.
С точки зрения офиса всё выглядело просто и логично. При импорте маршрутов из магистрали достаточно было выставить нужный local‑pref, чтобы сохранить схему active backup и направлять исходящий трафик в нужный туннель. Для входящего трафика работала другая логика: достаточно было проанонсировать корректный MED, чтобы трафик из магистрали затягивался в нужный стык — в конкретный туннель или в определённый бордер. Эта модель выглядела устойчивой и понятной, тем более что адресное пространство офисов и адреса лупбэк‑интерфейсов VPN‑концентраторов входили в суперсети Яндекса, анонсируемые с бордеров. На первый взгляд это удобно, но именно из‑за этого позже возникла серьёзная проблема.
Инфраструктурная сеть — всего лишь один из клиентов магистрали. Коллеги из Backbone хотели упростить подключение всех клиентов, создав унифицированный класс устройств и общие политики. Для этого появился отдельный класс устройств, к которым теперь подключалось офисное оборудование и с которыми велись пиринговые сессии.
Но инфраструктурные нужды ломали эту унификацию. Начали проявляться побочные эффекты: схема active backup перестала работать предсказуемо, а трафик не всегда шёл через нужный туннель. В некоторых случаях приходилось вручную добавлять AS‑prepend для регулирования приоритета, где‑то оказывалось невозможным протащить MED через внешние BGP‑сессии, и тогда приходилось использовать преобразование community в preference. Политики усложнялись, становились всё менее прозрачными, а роутмапы выглядели всё запутаннее. Коллегам из магистрали вместо простых и единообразных политик при подключении клиентов приходилось поддерживать отдельную кастомную логику только для инфраструктурной сети, что усложняло сопровождение и мешало унификации.
Классическая история: если уязвимость есть, она себя проявит. Как‑то раз произошёл инцидент на бордерах: из‑за ошибки в маршрутизации с них пропали анонсы суперсетей, а вместе с ними — и адреса лупбэк‑интерфейсов VPN‑концентраторов. Чтобы восстановить сеть, инженерам требовалось подключиться по OpenVPN, однако сам OpenVPN зависел от этих анонсов. Получилась классическая кольцевая зависимость — чтобы починить сеть, нужно было попасть в сеть, которая недоступна.
На тот момент у нас был всего один VPN‑концентратор, расположенный на адресе оператора связи. Все офисы строили по одному IPsec‑туннелю именно до этого адреса, но с минимальным приоритетом, поэтому в обычной ситуации через него трафик не ходил. Кроме того, на этом же адресе был запущен единственный экземпляр OpenVPN. Чтобы восстановить сеть, инженерам пришлось вручную изменить конфигурацию клиента OpenVPN на своих ноутбуках, прописать этот конкретный адрес вместо имени в настройках и подключиться напрямую. Через этот единственный VPN‑концентратор, который принимал трафик со всех офисов, они получили доступ к бордерам и смогли восстановить связность.
Этот случай показал, что внешняя связность магистрали Яндекса и инфраструктурной сети не должны зависеть друг от друга. Решением стало разделение. Дата‑центровая магистраль перестала быть транзитной автономной системой для инфраструктурной сети. Была выделена отдельная сущность — офисная магистраль, которая получила собственную автономную систему, собственное адресное пространство и независимые транзиты. Между двумя магистралями был сформулирован простой контракт: магистраль Яндекса анонсирует суперсети сервисов, а офисная — суперсети офисов. Такое разделение обеспечило полную независимость на уровне BGP и позволило каждой из сетей развиваться в своём темпе, с собственной архитектурой и политиками маршрутизации. Можно было менять топологию и маршрутизацию без риска сломать соседний контур.
Чтобы построить офисную магистраль, потребовалось развернуть отдельные бордеры и собственные транзиты на точках присутствия, выделить адресное пространство, которое можно агрегировать и анонсировать наружу. В результате инфраструктурная сеть приобрела самостоятельную магистраль, лишённую кольцевых зависимостей и готовую развиваться независимо от остального Яндекса.
Инцидент как катализатор эволюции
Однако, когда появилась собственная офисная магистраль и свои бордеры, стало очевидно: та же самая проблема может повториться уже в новой сети. Ведь теперь, если по какой‑то причине с бордеров офисной магистрали пропадут анонсы в интернет, ситуация окажется аналогичной — доступ к сети снова может быть потерян.
В этой схеме было три очевидные проблемы.
VPN‑концентратор с OpenVPN‑инстансами на адресах провайдера был только один, и если бы он упал, то мы потеряли бы последнюю точку входа.
IPsec‑туннели, ведущие к этому адресу, не использовались в штатной работе, а значит, мы не могли заранее узнать, как они поведут себя под нагрузкой.
OpenVPN‑инстанс хоть и выглядел «живым» по мониторингу, но это ничего не говорило о том, способен ли он реально обслуживать пользователей — до первого сбоя никто бы об этом не узнал.
Решение оказалось вполне прямолинейным. Во‑первых, мы развернули несколько VPN‑концентраторов на адресах операторов связи. Во‑вторых, изменили политику построения IPsec‑туннелей: теперь в каждом офисе создаётся один туннель до адреса оператора, и простой алгоритм определяет, какой из них активен. С вероятностью около одной трети каждый туннель становится активным для своего офиса. Это позволяет равномерно распределять нагрузку по всем концентраторам, поддерживать их в рабочем состоянии и заранее выявлять проблемы — если где‑то что‑то не так, мы узнаем об этом до того, как эт�� станет аварией.
OpenVPN мы тоже переработали. Раньше в конфигурации клиента был список серверов — несколько remote с FQDN, к которым пользователь мог подключаться. Теперь остался один FQDN (DNS SRV), который в DNS‑записи резолвится сразу в несколько лупбэк‑адресов, включая адреса провайдеров, где также запущены OpenVPN‑инстансы. Пользователи случайным образом подключаются к разным серверам, и это значит, что мы в реальном времени видим, что каждый экземпляр не просто работает, а действительно обслуживает сессии. Если с каким‑то из них возникает проблема, мониторинг замечает это почти сразу.
Вместо заключения
Эта история показала, что даже в пределах одной компании офисные и out‑of‑band‑сети можно строить по‑разному. У каждого подхода свои плюсы и минусы, разные области применимости. Но если смотреть с точки зрения Disaster Recovery, ключевой принцип остаётся один: резервирование и наблюдаемость, встроенные в систему по умолчанию. Мы вовремя заметили уязвимости с этой точки зрения, исправили ошибки и мониторим систему, чтобы не допустить подобных проблем.
В этом рассказе хотелось поднять более узкую тему: разделение дата‑центровой и инфраструктурной сетей. Буду рад продолжить общение на эту тему в комментариях!