Маршрутизация трафика между двумя филиалами через VPN-шлюз Azure
Два подключения «сеть — сеть» на одном VPN-шлюзе Azure могут пропускать трафик филиалов, но только когда оба конца узнают префикс и существует обратный путь в LAN.
Два филиала могут обмениваться трафиком через VPN-шлюз Azure без какого-либо прямого туннеля между ними. Каждый филиал открывает подключение «сеть — сеть» к одному и тому же шлюзу, и шлюз передаёт изученные префиксы между двумя подключениями. Работает это не благодаря второму туннелю, а благодаря обмену маршрутами: филиал A должен узнать префикс филиала B, а B — префикс A. Пройдите проверки ниже по порядку и остановитесь на первой неудачной, потому что каждый следующий шаг зависит от неё.
Предварительные условия, прежде чем что-то настраивать
Четыре условия решают, может ли такая схема вообще работать. Шлюз должен быть основан на маршрутах и работать на SKU с поддержкой BGP, на обоих подключениях должен быть включён BGP, адресные пространства филиалов не должны пересекаться, и ни одна сторона не должна полагаться на NAT, чтобы скрыть свой реальный префикс.
Планируйте ASN осознанно. Задокументированное значение по умолчанию в Azure — 65515, и каждому маршрутизатору филиала нужен собственный частный ASN, не конфликтующий со шлюзом или другим филиалом. Повторное использование значения по умолчанию без проверки существующей конфигурации шлюза — это способ, которым путь AS позже отклоняется.
Также убедитесь, что вы не ожидаете поведения пиринга VNet. Шлюз обменивается маршрутами между двумя настроенными подключениями; он не делает произвольные пиринги транзитивными. Если третьей сети нужно достичь обоих филиалов, ей нужно собственное подключение или собственный путь маршрута, а не предположение, что шлюз распределит трафик. Запишите эту границу до первого окна изменений, потому что это то проектное решение, к которому люди возвращаются, когда позже добавляется новый сайт.
Настраивайте в этом порядке
У каждого шага есть наблюдаемый результат, поэтому не двигайтесь дальше, пока он не появится.
- Включите BGP на шлюзе виртуальной сети и запишите его ASN и адрес партнёра.
- Создайте локальный сетевой шлюз для каждого филиала с его реальным адресным пространством, его ASN и адресом партнёра BGP.
- Создайте каждое подключение «сеть — сеть» и включите BGP на самом подключении.
- Настройте маршрутизатор филиала на пиринг с адресом шлюза, который назначил Azure, а не с публичной конечной точкой IKE шлюза по предположению.
Четвёртый шаг — место, где застревает большинство попыток. Адрес партнёра BGP, который сообщает Azure, — это тот, который маршрутизатор филиала должен использовать как соседа, и это не всегда адрес, который люди ожидают увидеть на схеме туннеля.
Анонсируйте сам префикс филиала, например 10.10.0.0/16 из A и 10.20.0.0/16 из B. Не анонсируйте маршрут по умолчанию или широкий агрегат, чтобы закрыть отсутствующую конкретную сеть; пробел позже вернётся тихой чёрной дырой.
Проверьте обмен маршрутами на обоих концах
Состояние подключения — это не проверка. IPsec может быть поднят на обоих подключениях, пока между ними не проходит ни один префикс. Прочитайте партнёров BGP шлюза и его изученные маршруты, затем подтвердите, что маршрут в сторону другого филиала отображается как пригодный путь.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Префикс, присутствующий в таблице BGP, всё ещё может проиграть решение о пересылке статическому маршруту или более конкретному префиксу. Проверяйте выбранный маршрут, а не только полученный.
Проследите обратный путь на стороне LAN
Это та часть, которая выглядит правильно в Azure и отказывает на месте. Хост в филиале A отправляет пакет маршрутизатору VPN филиала A, только если этот маршрутизатор является его шлюзом по умолчанию или если у хоста или его шлюза есть маршрут к префиксу B. То же должно быть верно и в обратном направлении.
Если отдельный магистральный коммутатор является шлюзом по умолчанию в LAN, ему нужен маршрут в сторону другого филиала, указывающий на маршрутизатор VPN. Без него запрос приходит, а ответ уходит интернет-путём, и пользователь видит соединение, которое открывается и затем зависает.
Не прибегайте к группе безопасности сети в подсети шлюза, чтобы это исправить. У этой подсети свои требования, и NSG там не является поддерживаемой заменой политики на стороне филиала. Фильтрация должна быть на межсетевых экранах филиалов и на самих рабочих нагрузках, где правила могут пересматривать их владельцы. Перенос этих правил в NSG подсети также скрывает их от команды, которая будет отлаживать следующий сбой.
Разрешите операцию, а затем докажите её запрещённым тестом
Изученный маршрут — это не разрешение. Разрешите источник, назначение и службу, которые действительно нужны, через межсетевые экраны филиалов и политику конечной точки, а остальное оставьте запрещённым.
Проверьте с обычной рабочей нагрузки в филиале A к реальной службе в филиале B, подтвердите ответ, затем попробуйте операцию, которая должна остаться запрещённой. Трафик, создаваемый самим устройством VPN, может использовать другой адрес источника и пропускать этап маршрутизации в LAN, поэтому успешный ping с маршрутизатора доказывает меньше, чем кажется.
Завершите, записав четыре факта: обменянные префиксы, используемые ASN, обратный путь LAN для каждой стороны и политику, допускающую службу. Если одного из них нет, настройка работает до первого изменения, а потом никто не может объяснить почему.