FortiGate Azure, перевыпуск ключа: предложение peer SA не совпадает с локальной политикой

Туннель поднялся, трафик пошёл, а позже в журнале появляется peer SA proposal not match local policy. Большинство читают эту строку как доказательство того, что две конфигурации никогда не совпадали. Обычно она означает более узкое: они совпадали для первой CHILD SA и перестали совпадать при первом обновлении, потому что первая ассоциация никогда не нуждалась в обмене, который выполняют последующие. Именно это различие определяет, где искать.

Первая CHILD SA наследует, последующие договариваются

В IKEv2 начальная CHILD SA создаётся во время IKE_AUTH, а её ключи выводятся из ключевого материала IKE SA. В этот момент отдельного обмена Diffie-Hellman нет, поэтому группа PFS, которую один peer не может принять, просто ещё не проверяется. Туннель выглядит здоровым, потому что требование, на котором вы позже провалитесь, никогда не проверялось.

Перевыпуск ключа CHILD_SA — это другая последовательность сообщений. Когда PFS настроен, peer выполняют новый обмен ключами и должны договориться о группе, принимаемой обеими сторонами, а также о предложении ESP для новой ассоциации. Именно в этот момент несоответствие становится видимым, и поэтому ошибка называет предложение, а не маршрут.

Так что «вчера работало» ничего не говорит о предложении. Оно говорит, что начальный обмен удался, что вы и так знали.

Читайте неудавшийся обмен, а не первый ping

Прежде чем что-либо менять, соберите с обеих сторон успешную аутентификацию IKE, начальную CHILD SA и неудачную замену. Затем назовите операцию точно: перевыпуск ключа IKE SA, повторная аутентификация IKE и перевыпуск ключа CHILD SA — это три разных события, и «фаза 2» в обычной речи охватывает их все.

Сравните поля ниже для соединения, которое не удалось, а не для туннеля вообще.

На FortiGate откройте предложение фазы-2, настройку PFS и принятые группы DH для этого туннеля. Читайте загруженные значения, а не выводите их из соединения, установленного ранее. Снимок экрана страницы GUI — более слабое доказательство, чем работающая конфигурация, потому что после обновления они могут разойтись. Экспортируйте изменённый раздел и сохраните его вместе с тикетом.

Политика Azure по умолчанию — всё ещё политика

Отсутствие пользовательской политики, привязанной к соединению, не означает, что Azure не применяет никакой. Соединение возвращается к набору предложений шлюза по умолчанию, который может быть шире или уже того, что предлагает ваш FortiGate. Если наборы пересекаются для IKE, но не для ESP с PFS, вы получаете именно такую картину отказа.

Это представление только для чтения показывает фактически привязанную политику, не раскрывая секретов:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

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

На портале страница Configuration этого соединения — это место, куда помещается пользовательская политика IPsec/IKE. Руководство Microsoft по пользовательским политикам перечисляет поддерживаемые параметры и требования к SKU. Azure берёт одну полную комбинацию на соединение, поэтому поля IKE и поля IPsec задаются вместе, а не по одному.

PFS — это требование, а не переключатель, который можно щёлкнуть

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

Одна ловушка, характерная для Azure: когда вы выбираете GCM для ESP, выбор шифрования и целостности должен называть один и тот же алгоритм GCM и одну и ту же длину ключа. Смешивание шифра GCM с отдельным алгоритмом целостности даёт комбинацию, которую служба отклоняет, и это выглядит как несоответствие peer, пока внимательно не прочитаешь политику.

Выберите самую сильную комбинацию, которую поддерживают оба конца и допускает ваше требование, затем запишите её в журнал изменений. Следующий человек будет сравнивать с этой записью, а не с воспоминанием о работающем туннеле. Внесите туда группу PFS и предложение ESP, а не только имя политики. Когда позже кто-то спросит, почему аудит не прошёл или почему перевыпуск ключа медленный, эта строка ответит на оба вопроса.

Проверьте обмен, который не удался

Планируйте изменение с путём восстановления, потому что правка политики может прервать туннель, который вы пытаетесь починить. После возврата трафика дождитесь обновления CHILD_SA или вызовите его и убедитесь, что новая ассоциация установлена с предполагаемой группой PFS. Затем убедитесь, что трафик приложений продолжается через неё.

Два ложных следа стоит назвать. Времена жизни SA — это локальные спецификации, поэтому неравные значения нормальны, и их изменение лишь сдвигает момент появления проблемы. DPD определяет, жив ли peer; увеличение его тайм-аута не выравнивает выбор ESP или PFS.

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