NAT в Azure VPN не решает проблему пересекающихся адресов VNet
Две VNet с одинаковым частным диапазоном не соединятся только потому, что есть NAT. Сначала проверьте тип подключения, затем перенумеруйте адреса или владейте псевдонимом трансляции.
Обе VNet используют 10.40.1.0/24, туннели поднимаются, и ничего не работает. Добавление второго шлюза VPN это не меняет, как и более низкая метрика маршрута, потому что проблема не в выборе пути. Две рабочие нагрузки, отвечающие на один и тот же частный адрес, оставляют каждый пакет с неоднозначным получателем и непроверяемым обратным путём. Прежде чем планировать какую-либо трансляцию, выясните, какой тип подключения вы действительно создали: именно этот выбор определяет, доступна ли функция NAT в Azure вообще.
Что на самом деле говорит этот симптом
Когда узел в VNet A отправляет на 10.40.1.10, таблица маршрутизации может только направить его куда-то. Если VNet B тоже содержит 10.40.1.10, этот адрес не является получателем, который путь может различить; это один адрес с двумя владельцами.
Второй шлюз, который обычно разворачивают, не помогает. Он даёт ещё один туннель, а не ещё один адрес, и дублирующийся диапазон идёт внутри туннеля без изменений. Он также удваивает конфигурацию, которую нужно держать согласованной. Чего он не может — сделать так, чтобы один адрес означал два узла.
Изменение публичных адресов партнёров VPN тоже ничего не даёт. Эти адреса определяют оконечные точки туннеля, тогда как конфликт находится в частном диапазоне, переносимом внутри.
Тип подключения определяет, доступен ли NAT
У Azure VPN Gateway действительно есть возможность NAT, и она документирована для маршрутных подключений IPsec между площадками на определённых SKU шлюза. Та же документация исключает подключения VNet-to-VNet и «точка — сайт», поэтому эта функция не является флажком, который появляется в любом отношении шлюза.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Собственный VNet-to-VNet также требует, чтобы диапазоны VNet и локальной сети изначально не пересекались, что согласуется с этим исключением. Объединение VNet в пиринг по той же причине не является решением проблемы пересечения.
Есть поддерживаемая альтернатива, которую путают с собственным типом: представить другую VNet как локальную сеть и подключить её как соединение между площадками. Это другой ресурс и другой проект, поэтому переименованное подключение следует воспринимать как изменение, требующее проверки, а не как простое переименование.
Перенумеруйте адреса или транслируйте с помощью того, что владеет псевдонимом
Если обе VNet ваши, сравните планируемую перенумерацию с постоянными затратами на трансляцию. Перенумерация затрагивает конфигурацию приложений, записи DNS, правила безопасности и каждое существующее подключение, но оставляет сеть, которая потом читается нормально. Делайте это по одной подсети, а изменение DNS — последним. Наполовину перенумерованный диапазон хуже любого из вариантов, потому что тогда оба префикса выглядят достоверными для того, кто прочитает таблицу следующим.
Там, где перенумерация нецелесообразна, используйте транслируемый проект с реальным владельцем псевдонима. Вызывающие из VNet A могут обращаться к 10.40.1.10 в VNet B как к 10.140.1.10, но этому псевдониму нужны устройство, выполняющее трансляцию, маршрут к нему и согласованное поведение для ответа. Адрес, добавленный только в DNS, не является трансляцией.
Зафиксируйте оба диапазона в обоих направлениях: что набирает вызывающая сторона, что получатель видит как источник и какая сторона может инициировать соединение. Собственные правила NAT в Azure включают обратную трансляцию для своих сопоставлений SNAT, поэтому соответствующее правило DNAT вручную не пишется, но это удобство заканчивается на типах подключений, которые поддерживает функция.
Что не сработает
Определяемый пользователем маршрут или метрика маршрута не могут создать недостающее различие адресов. Оба работают с получателем, который по-прежнему неоднозначен, и пакет приходит на тот следующий узел, который предпочитает таблица.
Добавление дублирующегося диапазона в таблицу маршрутизации как более конкретного префикса сдвигает неоднозначность только на один шаг. Оно также обычно ломает обратное направление, где у ответа теперь два вероятных источника.
Примите проект с трафиком в обоих направлениях
Докажите проект свежей разрешённой операцией с каждой стороны, а не состоянием туннеля. Подключённый туннель IPsec говорит, что партнёры согласны насчёт шифрования; он ничего не говорит о том, стали ли получатели различимыми.
Затем выполните запрещённые пути: адрес, который должен остаться недоступным, и служба, которую должна блокировать политика. Если оба по-прежнему успешны, трансляция шире, чем предполагал проект.
Завершите фактами, которые объяснят настройку позже: исходный диапазон, представленный диапазон, устройство, выполняющее трансляцию, и направление, в котором каждая сторона может инициировать соединение. Если чего-то из этого нет, следующий инженер унаследует сеть, где два узла делят одно имя и никто не помнит, почему один из них отвечает.