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

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

Требования сегодняшнего дня

Типичная конфигурация для многих инсталляций — это когда на межсетевом экране указан default route в Интернет или внешний периметр и static route прописан для защищаемых внутренних сегментов. Такой подход широко применяется, но, к сожалению, на сегодняшний день он во многом “устарел”.

Текущие условия требуют учитывать множество дополнительных составляющих:

• Наличие нескольких внешних каналов связи и нескольких провайдеров;

• Резервирование для устойчивого доступа в Интернет;

• Гибкое управление маршрутами для сервисов в зависимости от параметров каналов связи;

• Сочетание Интернет‑каналов и MPLS — соединений;

С внутренними сегментами ситуация также имеет свои нюансы:

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

• Ручное добавление маршрутов в условиях больших, распределённых сетей и высоких требований к доступности не может быть масштабируемо и создаёт задержки и риски.

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

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

RIP

Много лет назад, часто использовался протокол RIP. Сейчас этот протокол скорее встречается как требование обеспечить совместимость с какой-то старой системой которая была настроена много лет назад, то, что ранее было настроено, должно просто работать «как есть». Таким образом, наличие поддержки RIP часто диктуется необходимостью обеспечить совместимость со старыми системами.

Основные шаги настройки RIP

• Включаем RIP на интерфейсе

• Определяем версию RIP

• Добавляем метрику, чтобы поднять/понизить приоритет для маршрутов через RIP

• Выбираем получать или нет обновления RIP

• Определяем механизм транспорта

• При необходимости добавляем параметры для аутентификации

Чаще всего большинство параметров остаются “по умолчанию”, а размер RIP сети почти всегда минимален. В новых инсталляциях RIP полностью замещается OSPF и BGP.

OSPF

Протокол OSPF широко распространён, можно сказать, что используется повсеместно и является обязательным условием для межсетевого экрана.

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

Основные шаги настройки OSPF

• Задаём Router ID

• Определяем area

• Выставляем общие параметры (hello/dead, приоритеты, типы сети)

• Выбираем нужный интерфейс

• Добавляем вес для маршрутов

• Настраиваем аутентификацию, если требуется

Для межсетевых экранов важно, чтобы OSPF корректно взаимодействовал с политиками безопасности, т.е. как минимум помнить про необходимость разрешающих правил и работу NAT.

Пример реализации OSPF и static route для отказоустойчивого канала

Задача

Требовалось настроить отказоустойчивый канал связи для межсетевого экрана на периметре WAN. На площадке было два, независимых канала связи и было необходимо автоматически переключить сервисы на второй канал, если отказывал первый. Один из каналов при этом строился через VPN соединение, и он был основным для связи.

Реализация

Задача была решена настройкой OSPF через VPN. По протоколу OSPF делался анонс маршрута с более высоким приоритетом относительно static route который был настроен через резервный канал. Пока VPN был активен и туннель был доступен, маршрут через OSPF действовал, как только возникали проблемы со связью, трафик автоматически переключался на резервный статический маршрут.

Результат

Архитектура обеспечивала простую и надёжную схему резервирования, при которой восстановление соединения происходило без участия администратора и оставалось прозрачным для пользователей и сервисов.

BGP

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

BGP используется в режимах как Internal, так и External, иногда бывает, что необходимо их применять совместно на одном и том же оборудовании, один из таких примеров приведён ниже.

Основные элементы настройки External BGP

• Задаём AS number

• Определяем remote AS

• Выставляем общие параметры

• Создаём route-map

• Добавляем маршруты

• Указываем вес для маршрутов

• Выбираем нужный интерфейс

• Настраиваем аутентификацию, если требуется

Дополнительные настройки

• Для отказоустойчивого кластера надо предусматривать быстрое определение что узел не доступен и переключать BGP за 1–2 секунды.

• Иногда требуется использовать одновременно разные AS для работы с разными peer.

• Количество маршрутов получаемых по BGP может превышать 20 000, лимит по количеству должен быть высоким.

• Часто требуется анонсировать только какой-то тип маршрутов или фильтровать какие-либо сети

• Мониторинг доступности peer применяют как дополнительный фактор для переключения.

С настройками по умолчанию, конфигурации встречаются не очень часто, почти всегда нужно конфигурировать route-map, weight и local-preference для достижения нужной отказоустойчивости и предсказуемости переключений.

Пример реализации Internal и External BGP на одном устройстве

На площадке располагались два узла межсетевого экрана (FW1 и FW2), которые не были объединены в отказоустойчивый кластер. Оба устройства работали одновременно и имели собственные IP-адреса.

Задача

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

Реализация

Для обмена маршрутами между устройствами был настроен Internal BGP (iBGP), а для взаимодействия с внешними системами External BGP (eBGP) с общим для обоих узлов AS Number.

Проблема

При такой схеме возникла асимметричная маршрутизация: трафик, полученный через FW1, мог отправляться во внешнюю сеть через FW2 по внутреннему интерфейсу.

Решение

Для устранения асимметрии был применён параметр next-hop self, запрещающий пересылку трафика между FW1 и FW2 через внутреннюю сеть. Однако этого оказалось недостаточно и пришлось дополнительно использовать local-preference для управления приоритетом маршрутов на каждом узле.

Пример: BGP и policy-based VPN с автоматическим обновлением маршрутов

Задача заключалась в обеспечении отказоустойчивой связи между двумя площадками разных компаний.

На стороне A располагались два независимых межсетевых экрана (A1 и A2), на стороне B другие два межсетевых экрана (B1 и B2).

Между парами A1–B1 и A2–B2 были настроены VPN-туннели, обеспечивающие шифрование трафика.

Ограничения

Оборудование на площадках было от разных производителей и единственным совместимым вариантом оказался policy-based VPN. Использовать route-based VPN было невозможно.

Реализация

После установления туннеля соответствующий маршрут должен был объявляться в сети через BGP, чтобы внутренние узлы могли отправлять данные через активный межсетевой экран (A1).

Если туннель между A1 и B1 обрывался, маршрут автоматически перестраивался через A2 и B2. Выбор маршрута через A1 или A2 был реализован на основе BGP.

Особенностью конфигурации стало автоматическое обновление локальной таблицы маршрутов в зависимости от состояния VPN-туннелей.

Эта логика применялась симметрично на всех узлах (A1, A2, B1, B2) и обеспечивала полностью прозрачное переключение без вмешательства оператора.

Пример сочетания качества сервисов и динамической маршрутизации

Современный, показательный пример.

Клиент использовал технологию SD-WAN поверх BGP для управления выбором канала в зависимости от его качества, с учётом задержек и типа передаваемого трафика.

В результате корпоративные сервисы направлялись через выделенные каналы на другую площадку, а часть пользовательского трафика шла напрямую в Интернет. Все каналы (их было более четырёх) использовались одновременно, динамически перераспределяли нагрузку и обеспечивали прозрачную для пользователей работу сервисов.

Пример сочетания мониторинга соседей и возможных последствий

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

• Технология monitoring peer корректно удаляла маршрут при потере связи с каналом;

• Корректное удаление маршрута приводило к удалению маршрута на вышестоящем маршрутизаторе, в результате чего узел оказывался полностью изолирован;

Чтобы избежать подобных эффектов, стоит:

• согласовать таймеры SD-WAN-мониторинга и BGP-анонсов;

• предусматривать резервные статические маршруты или временные “stub routes”;

• использовать staged withdraw — постепенное снятие маршрута вместо мгновенного удаления;

• ограничивать влияние автоматических изменений локальной политикой, чтобы маршруты не удалялись глобально;

Вместо заключения

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

• Поддержка RIP, OSPF и BGP;

• Механизмы отказоустойчивости на уровне устройств, интерфейсов и маршрутов;

• Возможность комбинировать разные подходы и протоколы;

Всё что указано выше — это не дополнительные «фичи», а обязательные требования для корпоративных решений, особенно в крупных распределённых сетях.

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