Profil WireGuard dla bramy IPsec: o co zamiast tego zapytać

Przekroczenia czasu uzgadniania z milczącą bramą zwykle oznaczają dwa protokoły, które nigdy się nie spotykają. Peer WireGuard mówi Noise, podczas gdy brama IPsec czeka na IKE. Poprawny adres i port tego nie zmieniają.

Ponowne użycie punktu końcowego w profilu nie łączy obu. Następnym krokiem jest prośba do osoby zarządzającej bramą.

Pierwsza prośba: wersja protokołu

IPsec nazywa rodzinę, a nie jeden przepływ pracy. IKEv2 i IKEv1 różnią się wymianami, opcjami uwierzytelniania i zachowaniem przy zmianie sieci. Brama kończąca tylko IKEv1 zachowa się zupełnie inaczej niż ta oferująca IKEv2. Konfiguracja klienta zmienia się wraz z tym.

Zapytaj, którą wersję kończy usługa i czy działa na implementacji zgodnej ze standardami, czy na wariancie dostawcy z własnym klientem. Menu systemów operacyjnych często ukrywają tę odpowiedź za jedną etykietą. Etykieta nie jest protokołem.

Druga prośba: metoda uwierzytelniania klienta

Uwierzytelnianie to miejsce, w którym leży większość rzeczywistej pracy. Usługa może oczekiwać certyfikatu maszyny z określonym rozszerzonym użyciem klucza, certyfikatu użytkownika, metody EAP przez IKEv2 lub współdzielonego wcześniej klucza powiązanego z tożsamością. To, który z nich obowiązuje, decyduje o tym, czego potrzebuje klient.

Klucz prywatny WireGuard nie jest żadnym z nich. To klucz Curve25519 używany w jednym konkretnym uzgadnianiu. Żadna konwersja nie czyni go certyfikatem ani poświadczeniem EAP. Narzędzie, które twierdzi inaczej, zmienia nazwę pliku lub generuje coś niepowiązanego.

Specyfikacja IKEv2 w RFC 7296 opisuje, co musi obsługiwać implementacja tej wersji. To referencja dla niejasnej odpowiedzi operatora, a nie przewodnik po konfiguracji klienta.

Trzecia prośba: zaufana tożsamość i cele

Poproś o tożsamość bramy taką, jaką klient musi ją widzieć, oraz o kotwicę zaufania, która ją waliduje. Potem zapytaj, jakie prywatne zakresy i resolvery usługa wypycha. Te dwie odpowiedzi decydują, co tunel naprawdę przenosi.

Bez nich działające połączenie nadal może nie wykonać zadania. Tunel podniesiony bez wypchniętego resolvera pozostawia nazwy wewnętrzne bez odpowiedzi. Brakujący selektor ruchu pozostawia cel poza tunelem, mimo że uzgadnianie się powiodło.

Sonda punktu końcowego odpowiada na inne pytanie niż błąd klienta. Osiągalny port bez skojarzenia wskazuje na uwierzytelnianie, a nieosiągalny port na ścieżkę.

# 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

Wykonaj tę sondę, zanim zmienisz cokolwiek w kliencie. Jeśli porty odpowiadają, a skojarzenie nadal zawodzi, problemem są poświadczenia lub polityka. Jeśli nie odpowiadają wcale, żadna zmiana profilu nie pomoże.

Gdy oba protokoły muszą współistnieć

Administrowanie obiema sieciami to uzasadniony powód, by zachować oba protokoły. Typowy projekt kończy WireGuard i IPsec na osobnych interfejsach lub osobnych bramach. Zatwierdzony ruch jest następnie routowany między nimi.

Ten projekt wprowadza granicę zaufania i autoryzacji i powinien zostać tak zapisany. Które peery mogą przechodzić, w którym kierunku i pod czyją polityką, to decyzja o routingu i zaporze. Żaden z protokołów tego nie dostarcza.

Czym to nie jest, to przejrzysta konwersja. Ruch przychodzący przez WireGuard jest odtwarzany w tunelu IPsec, a każda polityka pomiędzy dotyczy go.

Najpierw wyjaśnij wymagania serwera dotyczące protokołu i uwierzytelniania. Następnie użyj klienta i ścieżki rejestracji obsługiwanej przez operatora, a klucze prywatne trzymaj z dala od konwerterów internetowych, gdy to się dzieje.