Site-to-Site VPN между AWS и Azure: сначала напишите обратный маршрут
Соединённый туннель между облаками ничего не доказывает, пока каждая подсеть нагрузки не маршрутизирует к удалённому префиксу. Пройдите план по порядку, затем проверьте сервис.
Туннель поднимется. Обычно так и бывает, потому что IKE нужны только совпадающие предложения и доступный адрес партнёра. А потом отказывает обратный путь: нагрузка в AWS отправляет пакеты в туннель, но на стороне Azure никто не знает, как ответить на 10.10.0.0/16, или маршрут Azure лежит в таблице, которую подсеть нагрузки не использует. Напишите план маршрутов до того, как трогать любую консоль, и туннель станет самой скучной частью работы.
Шаг 1: заморозьте план адресов
Работайте с конкретными значениями. Нагрузка в AWS находится на 10.10.1.20 внутри 10.10.0.0/16 и требует TCP 443 к сервису Azure на 10.20.1.30 внутри 10.20.0.0/16. Диапазоны не должны пересекаться, а приёмочный тест — это пара сервисов, а не туннель.
Запишите эти четыре факта раньше всего остального, потому что каждый следующий шаг проверяется по ним.
Шаг 2: назовите шлюз, которому принадлежит каждый конец
AWS Site-to-Site VPN может завершаться на виртуальном частном шлюзе или на транзитном шлюзе, и это разные владельцы маршрутизации. Azure предлагает управляемый VPN Gateway и отдельно устройства на базе ВМ, которые клиенты ведут сами. Запишите, какая пара у вас, потому что следующий шаг отличается в каждой комбинации.
Для управляемого шлюза не копируйте маршрут, указывающий на предполагаемый адрес частного устройства. Для устройства не предполагайте, что распространение маршрутов в облаке настраивает гостевую операционную систему, потому что это не так.
Ошибка здесь даёт план, который выглядит полным и отправляет пакеты на адрес, который никогда не отвечает.
Шаг 3: напишите маршрут, который реально использует каждая нагрузка
Каждая граница ниже — отдельный поиск, и маршрут в одной из них не является маршрутом для пакета. Заполните таблицу своими значениями до того, как туннель заработает.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
В AWS таблицу маршрутов подсети нагрузки обновляете вы, даже когда BGP или туннель в порядке; обзор маршрутизации считает это частью соединения. В Azure таблица маршрутов, заданных пользователем, связывается с подсетью, а не с виртуальной сетью, поэтому проверяйте действующий маршрут на NIC нагрузки, а не в панели VNet.
Управляемый шлюз Azure может выучить удалённый префикс через распространение шлюза, а UDR может отменить это решение. Добавляйте UDR, когда есть причина, а не рефлекторно. Если добавляете, направьте его на следующий переход, который шлюз публикует для пути VPN, вместо того чтобы придумывать адрес устройства. Затем перечитайте действующие маршруты на NIC, потому что решение принимается именно там.
Шаг 4: согласуйте охват
Для BGP сравните, что объявляет каждая сторона, с тем, что другая сторона действительно выучила, префикс за префиксом. Для статической маршрутизации сравните настроенные удалённые диапазоны с маршрутами нагрузки из шага 3.
Согласие IKE по криптографии не доказывает, что какая-либо сторона выучила 10.10.0.0/16 или 10.20.0.0/16. Два туннеля могут быть подняты, пока одна сторона объявляет один /24 вместо запланированного /16. Проверяйте префикс в таблице маршрутизации, а не в состоянии туннеля. Несоответствие проявится позже как одна работающая подсеть и одна, которая никогда не отвечает.
Шаг 5: проверьте сервис из реального источника
Разрешите предполагаемый поток в группах безопасности и сетевых ACL AWS, в NSG Azure и в любом фильтре устройства на пути. Затем откройте одно соединение с 10.10.1.20 на одобренные адрес и порт сервиса и убедитесь, что ответ возвращается к тому же источнику.
И группы безопасности облака, и NSG хранят состояние, поэтому отклонённый обратный пакет — симптом маршрутизации, а не правило, которое вы забыли написать в обратную сторону.
Ping с любого шлюза ничего не решает. ICMP на адрес шлюза тренирует путь плоскости управления, а не пересылаемый TCP-сервис, нужный нагрузке.
Откат и записи
Запишите владельцев маршрутов рядом с идентификаторами туннеля и сохраните таблицы маршрутов до изменения. Если изменение нужно снять, удалите маршруты нагрузки до разборки туннеля, чтобы ни одна подсеть не осталась указывать на следующий переход, которого больше нет.
Тогда последующий перенос подсети или подключение spoke имеет одно определённое место для обновления, а не работающий туннель, который несёт вину за маршрут, которым он никогда не владел.