VPN S2S в Azure подключён, но трафика нет: читаем журнал IKE

Портал пишет Connected, у туннеля есть счётчик времени работы, а трассировка с вашей виртуальной машины умирает на втором хопе. Состояние подключения описывает согласование IKE и IPsec, а не то, выживает ли хоть один пакет на уровне политик с любой стороны. Большинство таких заявок объясняют две неисправности, и ни одну из них не исправляет смена маршрута в Azure. Обе уже записаны в журнале, который создал шлюз, поэтому я начинаю оттуда, а не с таблицы маршрутов.

Что на самом деле подтверждает Connected

Подключённое соединение site-to-site означает, что фазы 1 и 2 завершены и ассоциации безопасности подняты. Это утверждение о согласовании: обе стороны договорились о предложении, обменялись ключами и установили пару SA. Оно ничего не говорит о том, совпадают ли селекторы трафика с подсетями, которые вы считаете защищёнными, и ничего о том, будет ли удалённая сторона куда-то маршрутизировать пакет после расшифровки. Туннель может стоять неделями, отбрасывая каждый интересный поток, и именно этот шаблон заставляет людей пересобирать здоровый шлюз.

Две неисправности, которые стоит проверить первыми, — это партнёр, предлагающий AH вместо ESP, и виртуальная сеть, пронумерованная в пространстве, которое шлюз не станет считать внутренним.

Откройте экспортированный журнал, прежде чем трогать маршруты

В портале откройте шлюз виртуальной сети и запустите операцию VPN troubleshoot для подключения, затем скачайте созданный пакет и распакуйте его. Внутри журнал IKE с обменами фаз 1 и 2, с отметками времени и читаемый как обычный текст. Ищите в нём строку transform, а не читайте сверху вниз, потому что интересная запись обычно находится через несколько сотен строк. Если доступа к порталу нет, та же диагностика появляется в месте назначения журналов шлюза, когда включены параметры диагностики.

Две записи несут основную ценность. Первая звучит примерно так: expected ESP with combined authentication and cipher, received AH. Вторая — ошибка недопустимого payload во время обмена IKE, что обычно означает неверно сформированное или неподдерживаемое поле предложения.

Обе описывают, что предложило локальное устройство, поэтому обе относятся к настройкам на стороне партнёра. Пересоздание стороны Azure не меняет предложение, которое отправляет ваш межсетевой экран, и делать это всё равно — самый часто теряемый час в этом процессе. На партнёре задайте фазу 2 в ESP с объединённой аутентификацией и шифром и дайте ему согласовать алгоритм, а затем проверьте, не выбирает ли тихо флажок поставщика с названием вроде combined mode предложение AH под ним.

Подтвердите адресное пространство виртуальной сети

Шлюз ожидает, что виртуальная сеть находится в частных диапазонах. Сеть, пронумерованная в публичном блоке, например начинающаяся с 111.x, может поднять туннель, но Azure откажется считать это пространство внутренним, поэтому подключение выглядит здоровым, а ни один поток не принимается. Подтвердите адресное пространство, прежде чем потратить полдня на селекторы. Если нумерация — жёсткое требование из старого распределения, исправление состоит в смене плана адресов, а не в другом шлюзе.

Запишите перекрытие с локальными диапазонами, пока вы в колонке адресного пространства, потому что перекрывающиеся префиксы дают другую неисправность, которая со стороны клиента выглядит похоже.

Проверьте префиксы в обоих направлениях

Ресурс шлюза локальной сети содержит локальные префиксы, и они должны совпадать с подсетями, которые удалённое устройство действительно защищает. Сводка, включающая адреса, которые устройство отбрасывает, пропустит одни потоки и провалит другие, и это читается как периодическая неисправность маршрутизации, а не как несоответствие конфигурации. Проверьте и удалённую сторону: один конец перечисляет /16, а другой — три /24 внутри него, это классический частичный отказ. Ни один список не является авторитетным сам по себе, поэтому сравните их рядом, а не доверяйте тому, который видите.

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

Проверяйте путь, а не ping

Трассировка, которая отличает работающий туннель от работающего маршрута, выглядит так: первый хоп — локальный шлюз, затем несколько неотвечающих хопов, затем удалённый хост отвечает. Если трассировка так и не доходит до хоста, проверьте TCP-порт, который приложение действительно использует, потому что ICMP фильтруется достаточно часто, чтобы неудачный ping доказывал очень мало. Запустите ту же трассировку с удалённого хоста в сторону виртуальной машины в Azure. Асимметрия между двумя результатами — самый быстрый способ найти отсутствующий обратный маршрут или правило, разрешающее только одно направление.

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

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