Резервирование каналов связи: Часть 4 — Выход в интернет: BGP, DNS failover и CDN

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

Два провайдера без BGP

Самая доступная схема: два провайдера, у каждого свой адрес, и маршрутизатор с автоматическим переключением.

Маршрутизатор проверяет не просто наличие линка до провайдера, а доступность интернета за ним. Для этого пингуют внешний адрес, доступный только через конкретного провайдера. В MikroTik RouterOS это делается рекурсивными маршрутами:

/ip route
add dst-address=8.8.8.8/32 gateway=203.0.113.1 scope=10
add dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2

Первая строка отправляет проверочный адрес только через основного провайдера (203.0.113.1). Маршрут по умолчанию с distance=1 указывает на этот адрес и проверяется пингом: RouterOS отправляет проверку раз в 10 секунд и после двух неудачных ответов считает шлюз недоступным. Тогда трафик переходит на маршрут через резервного провайдера (distance=2). Подробности — в документации MikroTik, раздел Failover (WAN Backup).

Ограничения схемы:

• Переключение занимает десятки секунд, и открытые соединения обрываются: у второго провайдера другой внешний адрес.
• Входящие подключения работают по двум разным адресам. Ответы должны уходить через того провайдера, через которого пришёл запрос, — см. «MikroTik: возврат трафика через тот же шлюз». Чтобы клиенты находили сервис при отказе одного провайдера, нужен DNS с проверками (ниже).

Для офиса этого обычно достаточно. Для публичных сервисов — не всегда.

BGP multihoming: одни адреса через двух провайдеров

Чтобы ваши адреса оставались доступны при отказе любого провайдера, нужна собственная автономная система (AS) и собственный блок адресов, которые вы анонсируете обоим провайдерам по протоколу BGP. Весь интернет видит два пути к вашей сети и при отказе одного пользуется другим.

Что для этого нужно

• Номер автономной системы. В регионе RIPE NCC (Европа, Ближний Восток, Россия) политика требует, чтобы сеть была подключена минимум к двум провайдерам и имела собственную политику маршрутизации. Номер получают через членство в RIPE NCC или через спонсирующего LIR — организацию-посредника, например провайдера.
• Блок IPv4-адресов. Свободные IPv4-адреса у RIPE NCC закончились. Новые члены, ранее не получавшие IPv4, могут встать в лист ожидания на один блок /24 (256 адресов); ожидание длится больше года. Заявки проверяются по санкционным спискам ЕС. На практике адреса арендуют или покупают на вторичном рынке, либо получают блок от одного из провайдеров с его согласием на анонс через второго — это обсуждается с провайдерами заранее.
• Маршрутизатор с поддержкой BGP и договорённость с обоими провайдерами о BGP-сессии.

Как быстро BGP переключается

Распространённое заблуждение — «BGP переключает за секунды». Если отказ не виден на уровне линка (например, сломалось оборудование за стыком), BGP узнаёт о нём по таймеру удержания. RFC 4271 предлагает по умолчанию 90 секунд, и некоторые производители используют ещё большие значения. Кроме того, изменениям нужно разойтись по интернету.

Ускорить обнаружение отказа позволяет BFD (RFC 5880) — лёгкий протокол, который обменивается пакетами с интервалом в сотни миллисекунд и сообщает BGP об отказе почти сразу. Его нужно согласовать с провайдером. На своей стороне таймеры BGP можно уменьшить, но слишком агрессивные значения приводят к ложным срабатываниям.

DNS failover

Если серверов несколько (или у одного сервера два провайдера с разными адресами), переключение можно делать на уровне DNS: сервис DNS проверяет доступность адресов и отдаёт клиентам только работающие.

• Нужны именно проверки. Простая раздача нескольких A-записей по очереди (round robin) не отслеживает отказы: часть клиентов продолжит получать адрес неработающего сервера.
• Короткий TTL (60–300 секунд), иначе клиенты будут держать старый адрес до истечения кеша. Часть резолверов и браузеров кеширует дольше, поэтому переключение не мгновенное.
• Сам DNS тоже резервируется: зону обслуживают несколько серверов в разных сетях.

DNS failover не требует своей AS и подходит, когда допустимы минуты переключения.

CDN

Сеть доставки контента хранит копии статических файлов (а иногда и страниц) на серверах по всему миру и отдаёт их пользователям с ближайшего узла. При кратковременной недоступности исходного сервера CDN может продолжать отдавать закешированное, а также принимает на себя часть DDoS-атак.

Для российской аудитории есть важное ограничение. С 9 июня 2025 года российские провайдеры, в том числе Ростелеком, МегаФон, Билайн и МТС, ограничивают трафик к сайтам за Cloudflare: пользователям загружаются только первые 16 КБ каждого ресурса, и сайты перестают работать. Cloudflare подтвердил это и сообщил, что не может обойти ограничение со своей стороны. Если ваша аудитория в России, выбирайте CDN с узлами в России.

Облака и несколько площадок

Для сервисов с высокими требованиями резервируют не только каналы, но и сами серверы: копии приложения работают в разных зонах доступности облака или в разных дата-центрах, а трафик между ними распределяет балансировщик или DNS. Это уже вопрос архитектуры приложения и репликации данных, а не только связи.

Что выбрать

Типичные ошибки

• Проверка по линку, а не по доступности интернета. Линк до провайдера есть, а интернета за ним нет, и маршрутизатор не переключается.
• Round robin DNS вместо failover.
• Длинный TTL в записях сервиса, которому нужно быстрое переключение.
• BGP без BFD в расчёте на мгновенное переключение.
• CDN, недоступный целевой аудитории.
• Резервный канал без мониторинга: о его отказе узнают в день аварии основного.