VPN между сайтами в Azure с партнёром за NAT: контрольный список

Выполняйте эти проверки по порядку и остановитесь на первой, которая не пройдёт. Большинство сообщений о том, что Azure не поддерживает устройство за NAT, на деле оказываются адресом партнёра, до которого Azure не может достучаться, или туннелем, который никогда не инициируется с правильной стороны. Внешний транспорт и внутренняя маршрутизация — две разные проблемы, и их смешение стоит половины дня. Каждый шаг ниже даёт наблюдение, которое можно передать другому человеку.

Шаг 1: убедитесь, что партнёр вообще находится за NAT

Сравните адрес на WAN-интерфейсе устройства с адресом, который Azure видит для него. Если они различаются, что-то транслирует, и этот транслятор теперь часть вашей схемы VPN. Спросите у провайдера, статическое ли сопоставление или общее, потому что общее сопоставление меняет то, на что можно рассчитывать. Устройство с частным WAN-адресом и без перенаправления — иной случай, чем устройство за NAT операторского уровня со стабильным публичным сопоставлением.

Если оба адреса совпадают, остановитесь здесь: NAT — не ваша проблема, и остальная часть списка не поможет.

Запишите оба адреса и модель транслятора в тикет. Эта одна строка предотвращает следующий круг вопросов о том, почему настроенный партнёр не отвечает.

Шаг 2: договоритесь, кто инициирует

Часто задаваемые вопросы по Azure VPN Gateway указывают поддержку NAT-T и добавляют, что локальное устройство должно инициировать туннель IPsec, когда оно находится за NAT. Это соответствует тому, как работает трансляция с сохранением состояния, поскольку транслятор держит сопоставление потому, что внутреннее устройство отправило первый пакет. Если ожидается, что инициирует Azure, а ничего не приходит для создания этого сопоставления, туннель никогда не запускается.

Настройте партнёра так, чтобы ошибка «только отвечающая сторона» была очевидной, и проверьте, повторяет ли устройство попытку само или ему нужен триггер. Некоторые устройства поднимают туннель только при появлении интересующего трафика, что нормально, пока интересующим трафиком не окажется проверка состояния, которая никогда не приходит.

Наблюдайте за обменом IKE на устройстве при ручной инициации; тишина там — это ответ маршрутизации или межсетевого экрана, а не ответ Azure.

Шаг 3: правильно задайте адрес партнёра

Azure нужен достижимый публичный адрес партнёра в объекте локального сетевого шлюза, обычно публичный адрес транслятора, а не внутренний адрес устройства. Идентичность, которой устройство аутентифицируется, — отдельное поле, и она может законно отличаться от адреса, на который звонит Azure. Держите их раздельно, потому что их перестановка даёт ошибку аутентификации, выглядящую в точности как проблема NAT.

Если публичный адрес меняется, этот объект должен меняться вместе с ним. Имя, которое разрешается в устаревший адрес, хуже статического адреса, который приходится обновлять вручную.

Запишите все три значения: локальный адрес устройства, транслированный публичный адрес и настроенную идентичность партнёра.

Шаг 4: откройте только те порты, которые нужны NAT-T

NAT-T переносит ESP внутри UDP, и RFC 3948 описывает эту инкапсуляцию с портом 4500, который используется после начальных переговоров на порту 500. Ваш межсетевой экран и транслятор должны оба разрешать обмен и его обратный трафик. Разрешение несвязанного TCP-порта ничего не доказывает про этот путь, а правило, разрешающее исходящий трафик, но не ответ, всё равно не сработает.

Статическое перенаправление входящего порта не требуется автоматически, когда партнёр инициирует, а транслятор держит состояние. Оно становится нужным, когда сопоставление нестабильно или когда что-то на пути агрессивно истекает состояние.

Снимите дамп с обеих сторон транслятора один раз; разница в инкапсуляции видна сразу.

Шаг 5: отделите внешний транспорт от внутренней маршрутизации

Туннель, который устанавливается и ничего не переносит, — это проблема маршрутизации, а не NAT-T. Сайтам по-прежнему нужны совместимые селекторы трафика, совпадающие адресные пространства, правила доступа и обратный путь для сетей приложений. Ничего из этого успешный обмен IKE не даёт.

Если два сайта используют перекрывающиеся частные диапазоны, трансляция внутри туннеля — отдельная схема со своими правилами. Не перенумеровывайте подсеть только потому, что внешний шлюз случайно стоит за домашним маршрутизатором.

Прежде чем что-либо менять, классифицируйте сбой по этапу и сохраните эту классификацию в тикете, чтобы следующий человек начал там, где вы остановились.