Настройка IPv4/IPv6 маршрутизации на серверах

Настройка маршрутизации Linux: где рвётся связность сетей

Связность между подсетями рвётся не в момент отказа канала, а тише: сервис отвечает из одного сегмента и молчит из другого, часть сессий открывается, часть висит до таймаута. Потери пакетов на стыке выглядят как плавающая деградация — мониторинг показывает норму по загрузке, а прикладные проверки ловят единичные ошибки рукопожатия. Именно поэтому такие сбои ищут долго: сеть формально работает, а настройка маршрутизации Linux живёт набором правил, разбросанных по узлам.

Чаще всего причина — пересекающиеся адресные пространства. При слиянии контуров или подключении новой площадки одинаковые диапазоны начинают жить в двух местах, и маршрут с более длинным префиксом уводит трафик в чужой сегмент. Хост при этом уверен, что адресат локальный, и отвечает сам, минуя шлюз, — соединение устанавливается в одну сторону и обрывается в обратную.

Вторая линия проблем — асимметричный трафик. Запрос уходит через один маршрутизатор, а ответ возвращается через другой, и промежуточный фильтр, отслеживающий состояния соединений, отбрасывает его как неожиданный. Снаружи это читается как потеря пакетов на стыке: соединение поднимается через раз, а диагностика с разных узлов даёт разные результаты.

Отдельный класс — ручные записи в таблицах маршрутизации. Правило, добавленное под разовую задачу, переживает саму задачу, а после переезда узла остаётся с прежним адресом шлюза и тихо ломает путь. Такие записи расходятся между серверами, и отказ проявляется не сразу, а при следующем изменении схемы. Разбираем, как это закрывается.

Что даёт управляемая сетевая связность: измеримые эффекты

Управляемая связность — это когда путь трафика известен заранее, а не выясняется по факту аварии. Пять эффектов ниже измеряются на стенде до передачи в эксплуатацию, поэтому «стало лучше» подтверждается числами, а не ощущениями.

Время восстановления связи — секунды вместо часов

Отказ канала отрабатывает по заранее проверенному сценарию: маршрут уходит на резерв сам, без ручных правок и дежурного с консолью. Возврат сервиса укладывается в десятки секунд против времени, которое обычно уходит на диагностику.

Доля потерянных соединений — обрывы перестают быть фоном

Симметричные обратные маршруты и корректная фильтрация убирают потери, которые выглядели как «сайт то открывается, то нет». Доля оборванных сессий падает до уровня, заметного только в счётчиках, а не в жалобах.

Устранённый класс отказов — асимметрия путей и теневые подсети

Двусторонняя проверка маршрутов исключает асимметрию, при которой запрос уходит через один канал, а ответ не возвращается. Класс аварий «соединение есть, данных нет» перестаёт воспроизводиться в принципе.

Скорость изменений в сети — новый сегмент за один прогон

Новая подсеть, адресное пространство или второй оператор связи описываются декларативно и применяются без простоя. Изменение проходит тот же набор проверок, что и текущая конфигурация, поэтому правки больше не откладывают до окна обслуживания.

Предсказуемость поведения сети — единый источник истины

Адреса, подсети и маршруты живут в одном реестре (NetBox), а рабочие конфигурации собираются из него. Расхождение между документацией и фактическим состоянием не накапливается, и любую сеть можно развернуть повторяемо.

Варианты маршрутизации: статика, динамика, гибридная схема

Режим маршрутизации выбирают по двум параметрам: размер топологии сети и частота её изменений. Пока серверов десяток и подсети фиксированы, статические правила читаются за минуту, не требуют демона и восстанавливаются из конфигурации. Как только появляются резервные каналы и адресация меняется чаще раза в квартал, ручные таблицы начинают расходиться между узлами.

Ниже — три схемы, между которыми реально выбирают. Без оценочных «лучше/хуже»: у каждой есть топология, где она уместна, и своя цена.

Границу между зонами фиксируем письменно: какие префиксы анонсируются, откуда приходит маршрут по умолчанию, что происходит при падении основного шлюза. Это снимает главный риск гибрида — уверенность, что «оно само разрулит».

Как проходит внедрение: от разбора схемы до передачи

Работы идут последовательно: сначала фиксируем фактическое состояние сети, затем проектируем целевое, и только потом меняем настройки на боевых машинах. На каждом переходе есть точка возврата — если поведение трафика расходится с проектом, возвращаемся на предыдущий шаг, а не ищем причину вслепую на работающем сервисе.

1. Сбор схемы сети. Инвентаризируем интерфейсы, адресные планы, таблицы маршрутизации, правила фильтрации и то, как трафик фактически ходит между сегментами. Расхождения между документацией и реальными настройками всплывают именно здесь — на бою они обернулись бы потерей связности.

2. Проект адресации и путей. Определяем префиксы, шлюзы, приоритеты маршрутов по умолчанию, порядок разрешения имён и поведение при отказе одного из путей. Получаем схему, где адрес и маршрут назначены осознанно, а не остались «как исторически сложилось».

3. Настройка. Переносим проект в конфигурации: интерфейсы, статические маршруты, отдельные таблицы для разделения потоков, фильтры. Изменения вносим повторяемо и храним в репозитории, чтобы стенд, тест и продуктив не расходились между собой.

4. Проверка на стенде. Прогоняем сценарии: смена адреса, потеря вышестоящего канала, асимметричный возврат трафика, смешанные режимы IPv4 и IPv6. Замеряем время сходимости и восстановления связности — на продуктив идём только с этими цифрами.

5. Контролируемый перенос. Переключаем по одному узлу или сегменту, в согласованном окне и с планом отката: прежние конфигурации сохранены. Доступность сервисов подтверждаем запросами из внешних точек, а не с самого сервера.

6. Передача документации. Отдаём актуальную схему адресации и маршрутов, карту зависимостей, шаблоны конфигураций, порядок отката и чек-лист проверки после изменений. Ваши инженеры смогут повторить настройку и точечно её изменить без обращения к нам.

Что остаётся у вас: конфигурации, схемы, регламенты

Всё, что мы настраиваем, остаётся в вашем репозитории и работает без нашего участия: поднять маршрутизацию на новой площадке или вернуть прежнее состояние можно по документам, не разыскивая автора изменений. Ниже — набор артефактов, который передаётся по каждому контуру.

• Конфигурации маршрутизации — декларативные файлы с адресами интерфейсов, шлюзами, статикой и отдельными таблицами; применяются одной командой, а состояние после перезагрузки сверяется автоматически.
• Схема адресации — какие префиксы закреплены за сегментами, где включены оба протокола, что отдано сервисам, шлюзам и служебным сетям, с резервом под расширение.
• Правила фильтрации — что и куда разрешено между сегментами, привязано к сервисам, а не к конкретным хостам: новая машина не требует правки политики.
• Правила маршрутизации по политике — какой трафик идёт через какой канал и как система ведёт себя при отказе основного.
• Порядок изменений — ветка, проверка на стенде, окно применения, откат: заранее видно, какие правки безопасны в рабочие часы.
• Инструкция для дежурной смены — как за минуты отличить проблему маршрута от сработавшего фильтра и какие данные снять до подключения инженера.
• Карта связности — потоки между площадками и внешними сервисами, точки выхода в сеть и резервные пути.

Артефакты лежат рядом с кодом и версионируются: историю правок видно, состояние на любую дату восстанавливается. Передачу закрываем разбором с вашей командой и дежурной сменой — чтобы документы не остались непрочитанными.

Кейс: переключение оператора без обрывов связи

До: смена оператора как плановая авария

Распределённая сеть из нескольких площадок выходила в интернет через одного оператора, а резервный канал включался вручную: инженер замечал деградацию, правил таблицу маршрутизации и перезапускал сессии. Переключение занимало от 12 до 40 минут, и всё это время рвались установленные соединения — выгрузки между площадками, клиентские сессии, каналы подрядчиков. Резерв формально был, но каждая смена оператора превращалась в простой сервиса.

После: переключение за секунды без потери соединений

Мы развели площадки на двух независимых операторов и перевели маршрутизацию на динамическую схему с проверкой доступности через отдельный путь. Маршрут выбирается по метрикам задержки и потерь: пока оба канала живы, трафик идёт по основному, при деградации уходит на резерв за секунды. Состояние активных соединений синхронизировано между пограничными узлами, поэтому и возврат на основной канал не рвёт сессии.

• простой при переключении: 12–40 минут → 3–5 секунд;
• потеря установленных соединений: при каждой смене оператора → единичные случаи только на плановых работах;
• ложные переключения: несколько за квартал → ноль;
• доступность внешнего контура: 98,2% → 99,94%.

Цифры подтверждают два независимых источника: телеметрия Prometheus и логи пограничных маршрутизаторов; внешние проверки с независимых точек дают ту же картину. Устойчивость каналов перестала зависеть от одного оператора и от ручных действий дежурного.

Чем автоматическое перестроение путей отличается от ручных записей?

Первая ось — реакция на сбой. При ручных записях таблица маршрутов остаётся такой, какой её оставил инженер: трафик продолжает идти в отказавший канал, пока дежурный не заметит проблему и не поправит конфигурацию. Автоматическое перестроение опирается на постоянный обмен служебными сообщениями между узлами — пропуск подтверждений снимает маршрут из активных, и трафик уходит по резервному направлению за секунды, без участия человека.

Вторая ось — сопровождение сети, то есть объём ручной работы. Статические записи ведут на каждом узле отдельно: новая подсеть, перенос сегмента, второй оператор связи — правку нужно разнести по всем конфигурациям и не пропустить ни одну. Динамическая схема описывает правила один раз: узлы сами сообщают о доступных направлениях, а веса и метрики задают приоритет. Чем больше точек и каналов, тем заметнее разрыв в трудозатратах.

Квалификация дежурной смены — третья ось. Ручные записи требуют, чтобы дежурный держал топологию в голове и просчитывал последствия правки: ошибка в адресе или маске уводит в отказ целый сегмент. Автоматика переносит эту работу на правила — достаточно проверить состояние соседства, метрики и наличие анонсов. Порог входа ниже, а круг людей, способных безопасно вмешаться в ночную смену, шире.

Предсказуемость изменений и выбор подхода связаны напрямую. Статическая схема прозрачна, но плохо переживает рост: связи между узлами приходится удерживать в документации и голове. Автоматическая перестраивается по заданным правилам, и результат правки проверяют до применения на рабочем контуре. На практике чаще берут гибрид: автоматика там, где нужна быстрая реакция на сбой, статика — на фиксированных стыках, где маршрут меняться не должен.

Частые технические сомнения перед началом работ

Перед началом работ заказчику важно понимать, как изменения отразятся на живом трафике. Ниже — ответы на вопросы, которые чаще всего задают перед настройкой маршрутизации Linux: они про сохранность текущих правил, проверку на регрессии, простой и распределение ответственности.

Как проверяете отсутствие регрессий?

До правок снимаем эталон: доступные маршруты, время отклика до ключевых узлов, состояние туннелей и балансировки. После — прогоняем тот же набор и сравниваем результат. Отдельно проверяем симметричность путей и поведение при отказе одного из каналов: маршрут должен перестроиться, а не оборвать соединение.

Нужен ли простой?

В большинстве сценариев — нет. Правила применяются точечно, без перезагрузки узла, а изменения вступают в силу на активных соединениях постепенно. Если архитектура требует переключения шлюза, выбираем окно минимальной нагрузки и держим его коротким: клиентский сервис видит только кратковременный рост задержки, а не разрыв.

Кто отвечает за сбой после внедрения?

Настройку, схему адресации и план отката фиксируем в документации — она передаётся вашей команде вместе с конфигурациями. Гарантийный период сопровождения входит в работы: если после смены обнаруживается отклонение в маршрутах, разбираем его и устраняем. Ответственность за изменения, внесённые уже после передачи, остаётся на вашей стороне.

Есть ли план отката?

Да, и он проверяется до, а не после внедрения. Сохраняем предыдущее состояние маршрутов и таблиц, готовим обратный набор команд и точку возврата конфигурации. Если контрольные проверки после переключения не проходят, стенд возвращается в исходное состояние за минуты — трафик идёт по прежним путям.

Что дальше: обсуждаем задачу и возвращаемся с планом

Чтобы вернуться с оценкой и планом внедрения, а не с общими словами, нам нужны вводные по инфраструктуре: маршрутизация на Linux-серверах почти всегда завязана на смежное оборудование и на то, как правила попадают на узлы. Ниже — то, что стоит прислать до обсуждения задачи.

• Текущая адресация: статические адреса или выдача по DHCP, сколько интерфейсов и подсетей на каждом узле, есть ли двойной стек IPv4/IPv6.
• Кто раздаёт маршруты: шлюз, маршрутизатор, балансировщик — и где сейчас описаны правила.
• Целевая логика: что должно ходить между подсетями, что нужно изолировать, где требуется выход наружу и трансляция адресов.
• Как правила попадают на серверы: вручную, шаблонами конфигурации или через систему управления — от этого зависит схема работ.
• Ограничения по окну работ: допустимый простой, есть ли резервный канал на время переключения.
• Доступы: тестовый контур для проверки, порядок согласования изменений, кто принимает результат.
• Как вы сейчас проверяете связность: трассировка, счётчики ошибок на интерфейсах, журналы.

Этого набора хватает, чтобы собрать схему работ и порядок проверки результата: сначала тестовый контур и контрольные точки связности, затем раскатка по узлам с возможностью отката, затем сверка с исходным состоянием. Опишите задачу — вернёмся с оценкой, планом внедрения и понятным порядком приёмки.