# 5. Байпас (Bypass) [← Оглавление](../README.md) · [← Раздел 4: Эшелонированная система](echelon.md) --- ## 5.1. Назначение и роль байпаса в ТСПУ Байпас — это устройство, обеспечивающее **физическую защиту каналов связи оператора** при установке ТСПУ. Каналы связи оператора физически разрываются и заводятся на байпас, который в штатном режиме прозрачно пропускает трафик дальше — в сторону балансировщика и фильтров. Основная задача байпаса — гарантировать, что связность сети оператора не будет нарушена при тех авариях, которые байпас способен обнаружить: потеря пути через ТСПУ (по heartbeat-пакетам), пропадание линка на портах Mon, зависание подключённого inline-устройства и потеря питания. В такой ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ; это последнее средство сохранить трафик оператора. При наличии балансировщика отказ отдельных фильтров байпас не отслеживает — его отрабатывает балансировщик программным байпасом группы портов ([раздел 6.6](balancer.md)); в схеме без балансировщика ([раздел 2.3](traffic-flow.md)) контур heartbeat замыкается на самом фильтре, поэтому отказ или зависание фильтра байпас видит и замыкает канал. Количество байпасов на площадке определяется **исключительно количеством линков оператора**, в разрыв которых устанавливается ТСПУ: каждый канал занимает на байпасе свою четвёрку портов (сегмент), а одно устройство может обслуживать один или несколько каналов. Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. Каждый байпас имеет management-интерфейс в сегменте управления площадки — под байпасы отведены первые 128 адресов management-подсети ([раздел 20.2](management-segment.md)). Термин «байпас» в документации ТСПУ используется в трёх значениях, которые важно различать: - **аппаратный байпас** — само устройство (Silicom, GL Sun) и его режимы, физически замыкающие канал оператора; предмет этого раздела; - **программный байпас** балансировщика — вывод из обработки отдельной группы портов в сторону фильтра при потере keep-alive или вручную, без участия аппаратного байпаса и без флапа линков у оператора ([раздел 6.6](balancer.md), [9.7](balancer-monitoring.md)); - **действие bypass** в правилах балансировщика — возврат определённого трафика оператору без анализа ([раздел 6.4](balancer.md), [8.7](balancer-config.md)). Ниже описано распределение оборудования на момент развёртывания федерального проекта; о более поздних поставках — см. [раздел 5.6](#56-развитие-отечественные-байпасы). В проекте АСБИ используются два типа аппаратных байпасов: | Проект | Производитель | Особенности | | ------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Федеральный** | Silicom | Активное устройство с режимами Inline, TAP, Active Bypass и Passive Bypass; переключение между первыми тремя без флапа линков; собственные heartbeat-пакеты | | **Пилотный (Урал)** | GL Sun | Оптический переключатель: только пропуск трафика или замыкание канала; каждое переключение — флап линков; heartbeat отправляет балансировщик (по TCP) или, на площадках без балансировщика, фильтр | ## 5.2. Байпасы Silicom (федеральный проект) Байпасы Silicom устанавливаются в рамках федерального проекта и обладают полным набором режимов работы, обеспечивающих гибкое управление прохождением трафика. Аппаратно это 1U-шасси со сменными модулями. В 100G-шасси устанавливается до двух модулей, каждый обслуживает один сегмент (четвёрку портов). В 40G/10G-шасси — до трёх модулей: 40G-модуль даёт один сегмент, двухскоростной 10G/1G-модуль — два, то есть до трёх сегментов 40G или до шести сегментов 10G/1G на шасси. Порты Net выведены оптическими разъёмами MPO/LC, порты Mon — гнёздами под сменные трансиверы. Шасси имеет два резервированных блока питания (AC или −48 В DC) и управляется через консольный порт, Ethernet-порт управления (Telnet/SSH, web-интерфейс) и SNMP v1/v2c/v3 с отправкой trap-сообщений; все сегменты шасси управляются централизованно. В терминологии производителя режимы называются Inline (Normal), Bypass, Tap и Linkdrop. Принятые в ТСПУ названия **Active Bypass** и **Passive Bypass** соответствуют двум схемам обхода в архитектуре Silicom Double Bypass: активной (электронной, управляемой программно и по heartbeat) и пассивной (оптической, срабатывающей при пропадании питания или отказе активной электроники). Режим Linkdrop, в котором оба сетевых порта принудительно гасятся, имитируя отключение кабеля, в описанной здесь схеме работы ТСПУ не задействован. ### 5.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) Для каждого канала связи байпас Silicom имеет **четыре порта**: - **Net0** и **Net1** — порты, подключаемые к оборудованию оператора: Net0 — к стороне абонентов (LAN), Net1 — к стороне интернета (WAN); - **Mon0** и **Mon1** — порты, подключаемые к балансировщику (или напрямую к фильтру в простейшей конфигурации): Mon0 — к LAN-порту линка, Mon1 — к WAN-порту. ```text Оборудование оператора Оборудование оператора (сторона абонентов, LAN) (сторона интернета, WAN) │ │ ┌────┴───────────────────────────────┴──────┐ │ Net0 Net1 │ │ Байпас Silicom (логика режимов) │ │ Mon0 Mon1 │ └────┬───────────────────────────────┬──────┘ │ LAN │ WAN Линк балансировщика (или пара портов фильтра) ``` Все соединения двунаправленные: каждая пара Net/Mon — полнодуплексный проходной сегмент. Байпас Silicom — активное устройство: в режимах Inline, TAP и Active Bypass сигнал операторских линков принимается собственной оптикой модуля (порты Net выведены разъёмами MPO/LC), а линки Mon0/Mon1 — отдельные, со сменными трансиверами. Состояние линка между сторонами не транслируется: падение порта балансировщика или отключение патч-корда Mon оператор не увидит как link-down — байпас обнаружит это сам, по пропаданию линка на Mon-порту или по прекращению возврата heartbeat, и переведёт сегмент в режим обхода ([раздел 5.5](#55-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)); падение линка оператора, наоборот, не видно на балансировщике. При диагностике нужно проверять состояние всех четырёх портов сегмента. В описании линка балансировщика рекомендуется указывать, к какому байпасу и какому его сегменту подключён линк ([раздел 8.4](balancer-config.md)). ### 5.2.2. Режим Inline — основной рабочий режим **Inline** — основной рабочий режим байпаса. В этом режиме трафик прозрачно пропускается насквозь от оборудования оператора к балансировщику и обратно: - Net0 → Mon0 (трафик от абонентов к балансировщику), Mon1 → Net1 (после обработки — в сторону интернета); - и симметрично для обратного направления: Net1 → Mon1, Mon0 → Net0. ```text Оборудование оператора (LAN) Net0 ◄══════► Mon0 ◄══════► LAN-порт линка Оборудование оператора (WAN) Net1 ◄══════► Mon1 ◄══════► WAN-порт линка путь абонент → интернет: Net0 → Mon0 → балансировщик → Mon1 → Net1 обратный путь — зеркально ``` Весь трафик оператора проходит через ТСПУ и подвергается анализу и фильтрации. Это штатный режим работы при нормальном функционировании всего оборудования. ### 5.2.3. Режим TAP — копирование трафика без влияния на оператора **TAP** — режим зеркалирования (копирования) трафика. В этом режиме: 1. Каналы оператора **замыкаются напрямую** между собой (Net0 ↔ Net1); 2. **Копия трафика** отправляется в сторону балансировщика: входящий трафик порта Net0 зеркалируется на Mon0, входящий трафик порта Net1 — на Mon1; 3. Пользовательские кадры, приходящие от балансировщика на Mon0/Mon1, в канал оператора не передаются и **отбрасываются** — повлиять на трафик оператора ТСПУ не может. Собственные heartbeat-кадры байпас распознаёт и терминирует на себе, поэтому контроль пути через балансировщик продолжает работать и в режиме TAP. ```text Net0 ◄────────────► Net1 ← канал оператора замкнут │ │ └──► Mon0 Mon1 ◄──┘ ← копия трафика (Net0 → Mon0, Net1 → Mon1); пользовательский приём с Mon-портов отбрасывается (heartbeat — терминируется) ``` В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это очень удобный **режим отладки**: можно настраивать систему фильтрации и выявлять проблемы при полной гарантии, что операторский трафик не пострадает. ### 5.2.4. Режим Active Bypass — замыкание без копирования **Active Bypass** — режим чистого обхода. Практически идентичен режиму TAP, за исключением того, что **копия трафика в сторону балансировщика не отправляется**: ```text Net0 ◄────────────► Net1 ← канал оператора замкнут ← операторский трафик к балансировщику НЕ идёт Mon0 Mon1 ← линки up, heartbeat продолжается ``` Каналы оператора замыкаются активной электроникой байпаса, ТСПУ полностью исключено из пути прохождения трафика. Порты Mon0/Mon1 при этом остаются включёнными: линки в сторону балансировщика не падают, операторский трафик на них не подаётся, но heartbeat-пакеты продолжают отправляться — благодаря этому байпас обнаруживает восстановление пути через балансировщик и возвращается в Inline. Режим включается программно — по команде или автоматически при потере канала до балансировщика ([раздел 5.5](#55-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)). ### 5.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала **Passive Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**, а также при отказе своей активной электроники (её контролирует внутренний сторожевой таймер). Каналы замыкаются на физическом уровне оптическим переключателем, который в обесточенном состоянии соединяет волокна Net0 и Net1 напрямую, минуя приёмопередатчики байпаса: ```text Net0 ◄═══════════► Net1 ← физическое (оптическое) замыкание Mon0 Mon1 (отключены от канала оператора) ``` Это **последнее средство** защиты трафика оператора. При переключении в этот режим: - у оператора **возможны флапы линков** (оптика «моргает»): устройства оператора начинают видеть друг друга напрямую и заново поднимают линк; - перерыв в трафике более существенный, чем при переключении между другими режимами; - оператор почувствует переключение — у него может начать перестраиваться маршрутизация; - обратный переход в Inline — это **второй флап**: оптический тракт снова переключается с прямого соединения Net0 ↔ Net1 на приёмопередатчики байпаса; - последствия более негативные, но это **аварийный** случай. Оптический бюджет для двух режимов считается по-разному. В режиме Inline каждая сторона оператора линкуется с сетевыми портами байпаса, поэтому бюджет — это своё плечо волокна плюс вносимые потери байпаса (по спецификации Silicom около 1–2 дБ; они присутствуют и в Inline, и в Passive Bypass). В режиме Passive Bypass устройства оператора линкуются напрямую друг с другом, и их трансиверы должны перекрывать сумму обоих плеч волокна плюс те же вносимые потери — это более жёсткое требование, и именно оно закладывается при проектировании стыка. Кроме того, на обеих сторонах канала должны стоять совместимые трансиверы: тип, длина волны, скорость и настройки FEC на 100G. ### 5.2.6. Переключение между режимами и влияние на оператора Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** выполняется активной электроникой без изменения состояния оптических линков оператора и происходит **безболезненно для оператора связи**: - порты оператора **не флапают** (не падают); - при ручном переключении теряются лишь единичные пакеты — те, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения; - при автоматическом переключении к этому добавляется время обнаружения аварии — окно контроля возврата heartbeat (по умолчанию 20 мс, см. [раздел 5.4](#54-мониторинг-каналов-heartbeat-пакеты-байпаса)), в течение которого трафик канала не проходит; - такие перерывы, как правило, **незаметны** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней. Сводная таблица режимов: | Режим | Трафик оператора | Трафик на ТСПУ (Mon0/Mon1) | Линки Mon | Влияние на оператора при переключении | | ------------------ | ---------------- | -------------------------------- | ------------------------ | ------------------------------------- | | **Inline** | Через ТСПУ | Весь трафик, в разрыв | up, heartbeat идут | Без флапа при входе из TAP/Active Bypass; с флапом — при выходе из Passive Bypass | | **TAP** | Замкнут напрямую | Копия (без приёма обратно) | up, heartbeat идут | Без флапа | | **Active Bypass** | Замкнут напрямую | Нет | up, heartbeat идут | Без флапа | | **Passive Bypass** | Замкнут напрямую | Нет | отключены от канала оператора (при обесточивании — down) | Флапы линков при входе и при возврате в Inline | ## 5.3. Байпасы GL Sun (пилотный проект, Урал) Байпасы GL Sun — оптические байпасы (производитель Guilin GLsun, КНР), используемые в рамках **пилотного проекта на Урале**. По сравнению с Silicom они значительно проще и имеют ряд существенных ограничений. ### 5.3.1. Отличие от Silicom: только пассивный байпас Байпас GL Sun — это оптический переключатель без собственных сетевых портов: в устройствах этого класса одно 1U-шасси защищает от одной до четырёх линий, время оптического переключения — единицы миллисекунд (по спецификациям GLSUN менее 8–10 мс), управление — по RS-232 и Ethernet (web-интерфейс и командный протокол поверх TCP). В применённой в пилотном проекте конфигурации байпас поддерживает **только один механизм переключения** — оптическое замыкание канала, эквивалент режима Passive Bypass у Silicom; режимов TAP и Active Bypass с безболезненным переключением у него нет. Фактически GL Sun умеет только: - **пропускать трафик** через себя (аналог Inline); - **замыкать канал** оптически (аналог Passive Bypass) — при пропадании питания, при прекращении heartbeat-пакетов или по команде. Требования к стыку те же, что и для пассивного обхода Silicom ([раздел 5.2.5](#525-режим-passive-bypass--аварийное-оптическое-замыкание-канала)): совместимые трансиверы с обеих сторон и запас оптического бюджета на вносимые потери переключателя. Для GL Sun это критичнее — прямое замыкание происходит при каждом переключении, а не только в аварии. Байпас GL Sun не генерирует heartbeat-пакеты самостоятельно — он работает как сторожевой таймер и лишь ожидает подтверждений от защищаемого устройства. Heartbeat-пакеты отправляет **балансировщик** (или **фильтр**, если балансировщика на площадке нет — на Урале есть несколько таких площадок), работая с байпасом в активном режиме. Обмен идёт по IP (TCP) на адрес байпаса через сеть управления, а не через порты данных, и байпас должен отвечать на эти пакеты; поэтому проверяется работоспособность самого балансировщика и сети управления, а не оптического пути через него: - на балансировщике задаются IPv4-адрес и порт байпаса, период отправки, группа балансировки, при активном состоянии которой отправляются heartbeat-пакеты, и список линков байпаса, для которых выполняется проверка (это сущности самого байпаса, например 01 и 02); дополнительно задаются тип сервиса и автоматический возврат трафика в основной режим после восстановления группы балансировки — не всегда полезная опция ([раздел 8.8](balancer-config.md)); - на фильтре (площадки без балансировщика) аналогичная секция bypass в конфигурации задаёт IP-адрес байпаса, интервал отправки и список каналов ([раздел 16.7](filter-acl-pools.md)). Состояние Bypass Watchdog держится в `active`, пока группа балансировки активна и байпас подтверждает приём. Если группа балансировки перешла в неактивное состояние, балансировщик перестаёт отправлять heartbeat-пакеты, состояние становится `disconnected`, и байпас оптически замыкает контролируемые линии ([раздел 9.7](balancer-monitoring.md)). Обратная сторона такой схемы: авария в сегменте управления сама по себе приводит к аппаратному обходу и флапу линков оператора, хотя тракт обработки трафика исправен — это надо учитывать при работах в сети управления площадок с GL Sun. Следствие для пилотного проекта: при потере связи даже с одним фильтром вся площадка переводилась на аппаратный байпас с флапом линков у оператора, а для возврата площадки в работу требовалось заводить работы и повторный флап; в федеральном проекте программно байпасится только затронутая группа портов балансировщика, без переключения аппаратного байпаса ([раздел 6.6](balancer.md)). В федеральном проекте эта схема **не актуальна**: байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность интерфейсов, поэтому логика работы с ними иная и на балансировщике для них ничего настраивать не нужно. ### 5.3.2. Флап линков при каждом переключении Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**: оптический переключатель физически меняет пару соединённых трансиверов (оператор ↔ ТСПУ на оператор ↔ оператор), и даже при времени переключения менее 10 мс приёмники на стороне оператора фиксируют потерю и повторное появление сигнала. Оператор видит падение и восстановление интерфейсов, что может приводить к: - перестройке маршрутизации на стороне оператора; - заметному перерыву в прохождении трафика; - необходимости согласовывать возврат площадки в работу как плановые работы — с повторным флапом. Безфлапового переключения, как у Silicom ([раздел 5.2.6](#526-переключение-между-режимами-и-влияние-на-оператора)), у GL Sun нет. ## 5.4. Мониторинг каналов: Heartbeat-пакеты байпаса Байпас Silicom осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**, которые генерирует сам, без участия внешнего программного обеспечения. Принцип работы: 1. Байпас отправляет heartbeat-пакет из порта **Mon0** (и одновременно — из порта **Mon1** в обратном направлении); 2. Пакет проходит через балансировщик: по требованию Silicom inline-устройство обязано прозрачно передать его с порта, подключённого к Mon0, на порт, подключённый к Mon1, и обратно — балансировщик делает это между парными портами линка без специальной настройки; 3. Пакет должен вернуться в порт **Mon1** (и, соответственно, Mon0); 4. Если пакеты проходят — байпас считает канал до балансировщика исправным и продолжает работать в режиме Inline. ```text Байпас Балансировщик ┌──────────┐ ┌──────────────────────┐ │ Mon0 ───┼──── heartbeat ──►│ LAN-порт линка │ │ │ │ │ │ │ │ │ мост между парными │ │ │ │ портами │ │ │ │ ▼ │ │ Mon1 ◄──┼──── heartbeat ───┤ WAN-порт линка │ └──────────┘ └──────────────────────┘ Зеркальный контур: Mon1 → WAN-порт → LAN-порт → Mon0 ``` По документации Silicom heartbeat-пакеты по умолчанию отправляются каждые 5 мс, а окно контроля составляет 20 мс; оба параметра настраиваются: интервал от 3 мс до 10 с, окно контроля от 10 мс до 50 с. Heartbeat-пакеты байпаса Silicom — небольшие служебные Ethernet-кадры; формат кадра задаётся в настройках байпаса. По умолчанию это IPX-пакет, то есть не IP; по запросу RDP.ru на устанавливаемых байпасах формат заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Балансировщик не отправляет такие кадры на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](traffic-flow.md)) их без обработки пропускает в парный порт фильтр, и контур проверки замыкается на фильтре. Важно: при наличии балансировщика heartbeat-пакеты байпаса **не доходят до фильтров** — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: 1. **Байпас → Балансировщик** — heartbeat-пакеты байпаса проверяют доступность каналов до балансировщика; 2. **Балансировщик → Фильтр** — keep-alive-пакеты балансировщика проверяют доступность и работоспособность фильтров (подробнее — в [разделе 6.6](balancer.md)). ## 5.5. Автоматическое переключение в TAP/Active Bypass при потере канала Если heartbeat-пакеты, отправленные через Mon0, не возвращаются в Mon1 (или наоборот) в течение окна контроля, байпас считает, что **канал связи до балансировщика неисправен**. Кроме потери heartbeat, байпас уходит в обход при пропадании линка на Mon-портах, при зависании подключённого inline-устройства и по команде оператора. В этом случае байпас **автоматически переключает** данный канал в безопасный режим: - **TAP** — если требуется сохранить копирование трафика для диагностики; - **Active Bypass** — если требуется полностью исключить ТСПУ из пути трафика. Выбор режима зависит от **настроек** конкретного байпаса. В обоих случаях переключение проходит без флапа линков у оператора. Heartbeat-пакеты продолжают отправляться и в этих режимах: когда путь через балансировщик восстанавливается и heartbeat снова начинают возвращаться, байпас автоматически возвращается в Inline. После подачи питания байпас стартует в режиме обхода и переходит в Inline только после того, как heartbeat-пакеты начинают возвращаться. ```text Штатная работа (Inline): Net0 ──► Mon0 ──► Балансировщик ──► Mon1 ──► Net1 heartbeat ✓ Потеря канала → автоматическое переключение: Net0 ◄────────────► Net1 ← замыкание (± копия на Mon0/Mon1, в зависимости от настроек; heartbeat продолжаются) ``` Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если выйдет из строя балансировщик или канал между байпасом и балансировщиком, каналы оператора будут замкнуты напрямую, и связность сети сохранится. При наличии балансировщика отказ отдельного фильтра байпас не видит — его обрабатывает балансировщик программным байпасом группы портов ([раздел 6.6.2](balancer.md)); в схеме без балансировщика контур heartbeat проходит через фильтр, поэтому его отказ приводит к переключению байпаса. Отдельно стоит помнить о возврате из **Passive Bypass**: он даёт второй флап линков оператора, поскольку оптический тракт снова переключается с прямого соединения Net0 ↔ Net1 на приёмопередатчики байпаса. Возврат площадки в работу после аварийного обхода поэтому согласуется с оператором как плановые работы. Побочный эффект возврата из байпаса в Inline: на фильтры сразу приходит большой объём трафика, и большинство сессий видны «с середины», без начального TCP SYN. Чтобы такие сессии заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](filter-interfaces.md)). ## 5.6. Развитие: отечественные байпасы По открытым данным, с 2022 года Silicom прекратил техническую поддержку своего оборудования для ТСПУ, и для проекта был разработан отечественный байпас: разработчиком решения называют компанию «Булат», программное обеспечение — RDP.ru, аппаратную часть — АО «Сигналтек». С 2023 года также тестируются оптические переключатели российского производства, созданные по заказу Роскомнадзора. В каталоге «Сигналтек» этому классу устройств соответствует байпас **SP100G4M «СигналПасс»**; прямое отождествление именно этой модели с поставляемым в ТСПУ устройством открытыми источниками не подтверждается. По описанию производителя, SP100G4M — это 1U-шасси с установкой до четырёх полнодуплексных модулей 10/40/100G, с резервируемыми блоками питания, сменными модулями вентиляторов и «горячей заменой» модулей, блоков питания и вентиляторов; коммутационная матрица — Intel Tofino, работоспособность внутреннего контура (DPI) контролируется периодической отправкой keep-alive. Заявленные режимы работы соответствуют привычной модели: **в линии** — аналог Inline, **байпас** — программный обход (аналог Active Bypass), **сниффер (TAP)** — аналог TAP. Наличие пассивного оптического замыкания при обесточивании по опубликованным характеристикам не подтверждается и уточняется по эксплуатационной документации конкретной поставки; влияние переключений на линки оператора в открытых источниках также не описано. Ранее установленные байпасы Silicom и GL Sun при этом остаются в эксплуатации, и описанные выше режимы для них актуальны. --- [← Оглавление](../README.md) · [← Раздел 4: Эшелонированная система](echelon.md) · [Раздел 6: Балансировщик: принцип работы →](balancer.md)