Маршрутизация в облаке и гибридных сетях: VPC, VPN и route tables в 2026 году

Облачная маршрутизация раскладывается на четыре уровня: адресация внутри VPC, таблицы маршрутизации, шлюзы и внешний обмен маршрутами с площадками. Пакет из подсети 10.0.1.0/24 уходит по маршруту 0.0.0.0/0 в интернет-шлюз, а трафик к 192.168.0.0/16 уходит через виртуальный приватный шлюз в туннель VPN или в выделенный канал. Облако выбирает путь по longest prefix match: /24 приоритетнее /16, /16 приоритетнее /0. Порядок строк в таблице на результат не влияет.

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

Пропускная способность туннелей, размер MTU, названия объектов и лимиты отличаются у AWS, Azure и Google Cloud и меняются между версиями сервисов. В статье приведены типовые значения, на которые опираются при проектировании; сверяйте их с официальной документацией своего провайдера перед запуском в продакшн.

Как устроена маршрутизация в облаке: базовые уровни и объекты

Четыре уровня стоит держать в голове по порядку, иначе отладка связности превращается в перебор гипотез.

1. Адресация. CIDR сети VPC и CIDR подсетей внутри неё.
2. Route tables. Правила вида destination CIDR -> target, привязанные к подсетям.
3. Шлюзы. Internet Gateway, NAT Gateway, Virtual Private Gateway, Transit Gateway, пиринговые соединения.
4. Внешний обмен маршрутами. BGP-сессии с on-premise и пропагация префиксов в таблицы облака.

Решение о пути принимается по longest prefix match. Для пакета к адресу 10.10.5.7 при маршрутах 10.10.0.0/16 -> Virtual Private Gateway и 0.0.0.0/0 -> Internet Gateway выиграет первый: у него длиннее префикс. Сортировка строк по важности ничего не меняет.

Пример рабочей подсети 10.0.1.0/24: default route 0.0.0.0/0 указывает на Internet Gateway, а маршрут 10.0.0.0/8 ведёт в Virtual Private Gateway к корпоративной сети. Такая подсеть публичная, её инстансы могут получать публичные адреса и быть доступны из интернета.

Route table ассоциируется с подсетью, не с виртуальной машиной. Перенос инстанса в другую подсеть меняет его маршрутизацию целиком, включая доступ в интернет. Правки применяются почти мгновенно, поэтому удаление маршрута в рабочей среде обрывает трафик сразу, без периода ожидания. Готовые схемы для трёх облаков с примерами Terraform и таблицами сравнения собраны в руководстве по сетевой маршрутизации в AWS, Azure и GCP.

Что такое VPC и как в нём живут подсети

VPC (Virtual Private Cloud) - изолированная сеть с заданным диапазоном адресов, например 10.0.0.0/16. Внутри неё создаются подсети, каждая привязана к одной зоне доступности. Внутри одного региона подсети не пересекаются по адресам, а разные VPC могут иметь одинаковые CIDR только до момента, когда вы захотите их соединить.

Публичной подсеть делает маршрут, а не имя. Достаточно строки 0.0.0.0/0 -> Internet Gateway, чтобы ресурсы подсети получили выход в интернет и возможность принимать входящие соединения. Приватная подсеть такого маршрута не имеет и выходит наружу через NAT либо не выходит вовсе.

Главный риск этого уровня - пересечение CIDR с on-premise. Если корпоративная сеть занимает 10.0.0.0/16, а VPC создан с тем же диапазоном, связать их через VPN или пиринг не удастся: облако не сможет различить локальные и удалённые адреса. Проверяйте план адресации до создания VPC, а не после, потому что диапазон IP-адресов существующей VPC или подсети изменить нельзя (AWS re:Post).

Route tables: как облако выбирает маршрут

Route table содержит правила destination CIDR -> target и одну локальную запись с CIDR самой VPC. Локальный маршрут создаётся автоматически и не удаляется: трафик внутри VPC ходит напрямую, минуя шлюзы.

Состояние blackhole возникает, когда target удалён, а запись осталась: NAT Gateway выключен, пиринговое соединение разорвано, VPN-туннель снят. Маршрут виден в таблице, но пакеты по нему отбрасываются. Проверка состояния маршрута входит в первый шаг диагностики и часто закрывает инцидент быстрее, чем анализ логов на серверах.

Одна подсеть ассоциируется ровно с одной таблицей, но одна таблица может обслуживать много подсетей. Это удобно для типовых схем: таблица public с маршрутом в Internet Gateway и таблица private с маршрутом в NAT Gateway. Как маршрутизатор выбирает путь между префиксами одинаковой длины и откуда берётся метрика, разобрано в руководстве по маршрутизации IP-пакетов.

NAT-шлюзы и исходящий доступ из приватных подсетей

NAT Gateway размещается в публичной подсети и получает Elastic IP. Инстанс из приватной подсети отправляет пакет на NAT, тот подменяет source-адрес на свой публичный, передаёт запрос в интернет и возвращает ответ инициатору. В route table приватной подсети для этого прописывают маршрут 0.0.0.0/0 -> NAT Gateway.

Правило, которое нарушают чаще всего: в приватной подсети не должно быть маршрута 0.0.0.0/0 -> Internet Gateway. С такой записью подсеть становится публичной по факту, исходящий трафик идёт мимо NAT, а ресурсы с публичными адресами оказываются доступны извне.

Выбор между управляемым шлюзом и NAT-инстансом сводится к балансу контроля и трудозатрат. NAT Gateway масштабирует пропускную способность автоматически, не требует администрирования ОС и оплачивается за час работы и за обработанный гигабайт. NAT Instance - обычная виртуальная машина с отключённой проверкой source/destination: дешевле в лаборатории, но масштабирование и отказоустойчивость вы настраиваете сами.

NAT Gateway привязан к одной зоне доступности, и AWS не создаёт его автоматически во всех зонах: при наличии нескольких подсетей в разных AZ требуется настроить несколько NAT Gateway для разных зон доступности (GlobalDots). Если шлюз размещён только в AZ-a, подсети в AZ-b не смогут использовать его для исходящего доступа, поэтому для продакшна поднимают отдельный NAT Gateway в каждой зоне доступности и прописывают в таблицах маршруты на локальный шлюз. Для IPv6 исходящий доступ организуют иначе, чем через NAT: сверяйтесь с документацией провайдера по поддерживаемым механизмам для IPv6.

Связка on-premise и облака: VPN и Direct Connect

VPN - туннель IPsec поверх интернета. Со стороны on-premise туннель поднимает Customer Gateway, со стороны облака его принимает Virtual Private Gateway или Transit Gateway. Direct Connect - выделенный физический канал до точки присутствия провайдера. Маршруты в обеих схемах чаще всего распространяет BGP, реже - статические записи для простых стендов.

Как BGP распространяет маршруты между площадками

BGP-сессия устанавливается между Customer Gateway и Virtual Private Gateway или Transit Gateway. Префиксы, которые анонсирует on-premise, например 192.168.0.0/16, попадают в route tables через route propagation: запись 192.168.0.0/16 -> Virtual Private Gateway появляется автоматически, без ручного добавления. Обратно облако анонсирует CIDR VPC, и корпоративные маршрутизаторы узнают адреса подсетей.

Опасный сценарий: on-premise анонсирует 0.0.0.0/0. Облако получает default route из туннеля, и весь исходящий трафик подсетей с включённой пропагацией уходит в корпоративную сеть. Если там нет выхода в интернет для этих адресов, внешние сервисы становятся недоступны, включая обновления пакетов и вызовы API. Анонсируйте только реальные префиксы, а default route добавляйте статически в те таблицы, где он действительно нужен.

Приоритетом управляют через AS path prepending и BGP communities. Удлинение AS path делает маршрут менее предпочтительным, поэтому резервный канал анонсируют с длинным путём, а основной с коротким. Готовые конфигурации BGP для Cisco, MikroTik, AWS Transit Gateway, GCP Cloud Router и Azure VPN Gateway с модулями Terraform приведены в практическом руководстве по динамической маршрутизации между серверами и облаками.

Когда выбирать VPN, а когда Direct Connect

VPN поднимается за часы и не требует работ на стороне оператора связи. В AWS каждое соединение Site-to-Site VPN состоит из двух туннелей, и каждый туннель поддерживает максимальную пропускную способность до 1.25 Гбит/с (AWS re:Post); задержка зависит от интернет-маршрута и не гарантируется. Direct Connect даёт физический порт со скоростью 1, 10 или 100 Гбит/с (GitHub), стабильную задержку и предсказуемые потери, но подключение занимает недели: нужен кросс-коннект в точке присутствия и согласование с оператором.

Рабочая схема для продакшна: Direct Connect как основной канал, VPN как резерв с анонсом через BGP. Пока основной канал доступен, трафик идёт по нему; при обрыве BGP-сессия падает и маршруты переключаются на туннель. Проверьте, что резерв выдержит нагрузку: 1.25 Гбит/с на туннель часто меньше пикового трафика прода, поэтому после переключения часть сервисов деградирует.

Для требований compliance на Direct Connect включают MACsec: он поддерживается на выделенных подключениях 10, 100 и 400 Гбит/с в отдельных точках присутствия и работает в двух режимах - should_encrypt и must_encrypt, причём новые MACsec-подключения по умолчанию устанавливаются в режим should_encrypt (Amazon Direct Connect). Альтернатива - VPN поверх выделенного канала. Шифрование меняет MTU: у туннеля полезная нагрузка меньше, чем у выделенного канала, поэтому при неверных настройках фрагментация ломает TLS-рукопожатия и SSH-сессии.

Пиринг VPC и Transit Gateway: связка нескольких сетей

VPC peering соединяет две сети напрямую, без транзита. Соединение не транзитивное: если VPC A связан с B, а B с C, то A не видит C, пока не создаст отдельный пиринг с C. Для каждого соединения нужно обновить route tables в обеих сетях, иначе маршруты не появятся.

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

Transit Gateway работает как хаб. К нему подключаются VPC, VPN и Direct Connect, а маршрутизацией между ними управляют таблицы самого TGW. Транзитивная маршрутизация встроена, число подключённых сетей измеряется десятками, а сегментация делается через отдельные route tables для прода и dev. Стоимость выше: платят за каждое подключение и за обработанный трафик.

Практическое правило выбора: для двух-трёх VPC пиринг проще и дешевле, для десятков сетей с гибридными площадками и централизованным контролем маршрутов выгоднее Transit Gateway. Подробное сравнение Transit Gateway, VNet Peering и Cloud Router по стоимости и производительности для схем hub-and-spoke дано в сравнении облачных сервисов динамической маршрутизации.

Типичные ошибки маршрутизации и конфликты маршрутов

Большинство инцидентов связности сводится к шести причинам. Их полезно держать в голове при проектировании, а не искать после сбоя.

• Пересекающиеся CIDR. Симптом: часть адресов недоступна, маршруты указывают в разные стороны для похожих диапазонов. Проверка: сверьте планы адресации VPC, on-premise и партнёрских сетей.
• Асимметричная маршрутизация. Запрос уходит через VPN, ответ приходит через Direct Connect. Stateful-межсетевой экран видит ответ без записи о сессии и отбрасывает пакет. Симптом: соединение не устанавливается, хотя трафик есть в обе стороны. Проверка: сравните маршруты туда и обратно на обоих концах.
• Blackhole-маршрут. Target удалён, запись осталась. Симптом: таблица выглядит корректно, трафик не идёт. Проверка: состояние маршрута в консоли и в логах изменений.
• Отсутствие route propagation. BGP-префиксы не попадают в таблицу, потому что пропагация не включена для нужной route table. Симптом: сессия в состоянии Established, а маршрутов к удалённой сети нет.
• Security group и NACL. Маршрут есть, но правила блокируют трафик. NACL работает без состояния, поэтому нужны правила в обе стороны, включая диапазон ephemeral-портов 1024-65535.
• MTU mismatch. Пакет с флагом DF не проходит туннель. Симптом: ping проходит, а SSH и TLS зависают на этапе рукопожатия.

Чек-лист диагностики: от route table до security group

1. Маршрут: проверьте route table подсети-источника и подсети-назначения. У обеих сторон должен быть маршрут друг к другу.
2. Состояние маршрута: убедитесь, что нет blackhole.
3. Security group: проверьте правила на обоих концах, включая исходящие.
4. NACL: проверьте входящие и исходящие правила отдельно, они обрабатываются независимо.
5. BGP: состояние сессии, анонсированные и принятые префиксы.
6. MTU: ping с запретом фрагментации и разными размерами пакета, чтобы найти рабочее значение.

Время экономят два инструмента. VPC Flow Logs показывают, дошёл ли пакет до сетевого интерфейса и был ли он принят или отклонён, с указанием направления и портов. Reachability Analyzer - инструмент анализа конфигурации, который проверяет связность между исходным и целевым ресурсами в VPC без запуска реального трафика и указывает конкретный компонент, блокирующий соединение (Amazon VPC Reachability Analyzer). Разбор алгоритмов выбора пути и команд диагностики на маршрутизаторах приведён в руководстве по работе маршрутизатора и настройке OSPF и BGP.

Планирование адресации и масштабирование на будущее

Адресацию закладывают один раз: диапазон IP-адресов существующей VPC или подсети изменить нельзя, можно только расширить сеть, добавив вторичный CIDR-блок. Если исчерпанный блок является вторичным, к VPC можно привязать ещё один CIDR-блок с новым диапазоном (AWS re:Post). Планируйте с запасом на три-пять лет: VPC уровня /16 вмещает 65 536 адресов, подсеть /24 - 256. Для продакшна обычно резервируют отдельные /16 на каждую среду.

Держите диапазоны RFC 1918 без пересечений: блок 10.0.0.0/8 делите между средами по /16, а для лабораторий и будущих площадок оставляйте свободные блоки заранее. IPAM (например, VPC IPAM в AWS или аналоги в других облаках) ведёт централизованный учёт выделенных префиксов и не даёт двум командам занять один диапазон.

Prefix lists группируют префиксы в одну сущность, на которую ссылаются правила security group и route tables. Когда появляется новая площадка, вы правите один список, а не десятки записей в разных таблицах. Это снижает вероятность расхождения конфигураций между средами.

Первый практический шаг для следующего проекта: составьте таблицу всех префиксов (VPC, on-premise, партнёрские сети), загрузите её в IPAM и только затем создавайте VPC. Сверка на пересечения занимает полчаса, а перестройка адресации работающей сети потребует пересоздания VPC и переноса ресурсов.