Профиль WireGuard для шлюза IPsec: о чём спросить вместо этого

Тайм-ауты рукопожатия с молчащим шлюзом обычно означают два протокола, которые никогда не встречаются. Узел WireGuard говорит на Noise, а шлюз IPsec ждёт IKE. Правильные адрес и порт этого не меняют.

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

Первый запрос: версия протокола

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

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

Второй запрос: метод аутентификации клиента

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

Закрытый ключ WireGuard — ничто из этого. Это ключ Curve25519, используемый в одном конкретном рукопожатии. Никакое преобразование не делает из него сертификат или учётные данные EAP. Инструмент, утверждающий обратное, переименовывает файл или создаёт что-то не связанное с ним.

Спецификация IKEv2 в RFC 7296 описывает, что должна поддерживать реализация этой версии. Это справочник для расплывчатого ответа оператора, а не руководство по настройке клиента.

Третий запрос: доверенная идентичность и назначения

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

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

Проверка конечной точки отвечает на другой вопрос, чем ошибка клиента. Доступный порт без ассоциации указывает на аутентификацию, а недоступный порт — на путь.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

Когда оба протокола должны сосуществовать

Администрирование обеих сетей — законная причина сохранить оба протокола. Обычная схема завершает WireGuard и IPsec на разных интерфейсах или разных шлюзах. Одобренный трафик затем маршрутизируется между ними.

Эта схема вводит границу доверия и авторизации, и её следует так и зафиксировать. Какие узлы могут пересекать границу, в каком направлении и по чьей политике — это решение по маршрутизации и межсетевому экрану. Ни один из протоколов его не даёт.

То, чем это не является, — прозрачное преобразование. Трафик, приходящий через WireGuard, заново создаётся в туннеле IPsec, и каждая политика между ними к нему применяется.

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