IKEv2 адрес сервера и личность: что на самом деле проверяет клиент

Шлюз, который меняет адрес, может продолжать работать, пока тот же шлюз за новым сертификатом останавливается, но происходит и обратное. Адрес сообщает клиенту, куда отправлять пакеты; аутентифицированная личность сообщает клиенту, является ли отвечающий одноранговый узел тем, которому он должен доверять. IKEv2 сохраняет их как два отдельных поля, что полезно, если вы перестанете рассматривать их как одну строку. Они также настраиваются в разных местах, поэтому один может быть правильным, а другой — нет.

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

Во-первых, какое значение является адресом

Адресом подключения является то, что набирает клиент: IP-адрес, имя DNS, которое разрешается в одно значение, или внешний интерфейс с балансировкой нагрузки. Это транспортная информация и не более того. Идентификатор содержится в полезной нагрузке идентификатора IKEv2 и затем сопоставляется с сертификатом узла. Имя DNS в поле адреса не становится ожидаемым идентификатором, а необработанный IP-адрес не становится идентификатором только потому, что к нему подключен сокет.

В терминах strongSwan адрес — это right или left, а ожидаемый идентификатор — rightid или leftid, и это то, что описывает документация по конфигурации IKEv2. Если вы когда-либо редактировали адрес только тогда, вы настроили половину пары.

Во-вторых, что может доказать сертификат

У удостоверения есть тип, и сертификат должен иметь соответствующее имя. Идентичность DNS удовлетворяется записью dNSName в расширении альтернативного имени субъекта; для идентификации IP требуется запись iPAddress. Сертификат, выданный для vpn.example.com ничего не доказывает о буквальном адресе 203.0.113.10, а сертификат, выданный для этого адреса, ничего не доказывает об имени. Таким образом, повторный выпуск под другим именем не является полной заменой, даже если повторно используются тот же ключ и CA.

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

В-третьих, как каждый клиент формулирует свои ожидания

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

На strongSwan ожидание является явным: установите rightid на идентификатор, который фактически представляет сервер, который может отличаться от правильного. Установка значения %any принимает все, что предлагает партнер, и удаляет именно ту проверку, которую вы пытаетесь сохранить.

В-четвёртых, отдельный логин пользователя от идентификатора однорангового узла

Аутентификация EAP и личность сервера отвечают на разные вопросы. Идентификатор EAP, такой как [email protected] говорит, кто является пользователем, после того как клиент решил, что сервер является правильным. Изменение этого пароля не может исправить несоответствие идентификаторов одноранговых узлов, поскольку соединение никогда не достигает стадии входа пользователя.

В очищенном отчете должны быть указаны оба: идентификатор, ожидаемый клиентом, идентификатор, предоставленный сервером, и записи сертификата SAN.

В-пятых, поменяйте его через проверенный канал

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

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