Профіль 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, і кожна політика між ними до нього застосовується.

Спершу з'ясуйте вимоги сервера до протоколу й автентифікації. Потім використовуйте клієнт і шлях реєстрації, які підтримує оператор, і тримайте приватні ключі подалі від веб-конвертерів, поки це відбувається.