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 тунела и всяка политика между тях се прилага към него.

Първо изяснете изискванията на сървъра за протокол и удостоверяване. След това използвайте клиента и пътя за регистрация, които операторът поддържа, и дръжте частните ключове далеч от уеб конвертори, докато това става.