IKEv2 to nie jedno uzgadnianie: IKE SA, uwierzytelnianie, potem CHILD SA
Odpowiedź bramy dowodzi osiągalności, nie tożsamości. Prześledź IKE_SA_INIT, IKE_AUTH i pierwszy CHILD SA, a potem sprawdź, co musi być prawdą, zanim popłynie ruch.
Możesz sądzić, że połączenie IKEv2 to jedna wymiana kończąca się zaszyfrowaniem ruchu. Są co najmniej dwie, a pierwsza nikogo nie uwierzytelnia. Strony zaczynają od komunikatów sterujących, uzgadniają parametry kryptograficzne, dowodzą tożsamości i dopiero potem negocjują stan, który przenosi pakiety aplikacji. Ta kolejność wyjaśnia rozbieżność, którą ludzie ciągle zgłaszają: brama odpowiada, klient pokazuje połączenie, a prywatna aplikacja wciąż przekracza limit czasu. Oto co naprawdę robi każdy etap i co musi być prawdą po nim.
Mit: jeśli brama odpowiada, jesteś połączony
Odpowiedź na pierwszy komunikat dowodzi, że punkt końcowy jest osiągalny i gotowy do rozmowy. Nie dowodzi, że konto zostało przyjęte, że łańcuch certyfikatów został zweryfikowany ani że zainstalowano jakąkolwiek politykę danych.
Te błędy pojawiają się później i dają inne objawy. Odrzucenie certyfikatu lub błąd EAP przychodzi po tym, jak pierwsza wymiana już się udała, dlatego ping do UDP 500 i zielona ikona klienta mówią tak niewiele.
IKE_SA_INIT: uzgodnij parametry, nie tożsamość
Pierwsza wymiana przenosi propozycje stowarzyszenia bezpieczeństwa IKE: algorytmy szyfrowania i integralności, funkcję pseudolosową i grupę Diffiego-Hellmana. Strony wymieniają też nonce, a każda strona wyprowadza materiał klucza dla IKE SA ze wspólnego sekretu, który tworzą te wartości. Nic w tej wymianie nie ustala, kim jest druga strona. Ustala tylko, że obie strony potrafią obliczyć te same klucze i zgadzają się co do jednej propozycji. Odpowiadający, któremu nie odpowiada żadna propozycja, odrzuca tu wymianę, dlatego niezgodność wersji lub algorytmu wygląda jak wyłączony serwer.
Utworzone w tym momencie IKE SA chroni wszystkie późniejsze wymiany zarządzające. To jego zadanie i jest to inne zadanie niż ochrona twoich pakietów.
IKE_AUTH: udowodnij tożsamość, a potem zbuduj pierwsze CHILD SA
Druga wymiana przenosi tożsamość. Z certyfikatami każda strona podpisuje się swoim kluczem prywatnym i przedstawia łańcuch, który druga musi zweryfikować; z EAP odpowiadający rzuca wyzwanie inicjatorowi wybraną metodą. Tu wreszcie ujawnia się zła nazwa serwera, wygasły certyfikat lub odrzucone hasło.
Zwykle IKE_AUTH negocjuje też pierwsze CHILD SA, więc ochrona danych jest uzgadniana w tej samej podróży. Inicjator proponuje selektory ruchu, odpowiadający je zawęża lub odrzuca, a klucze ścieżki danych są wyprowadzane z IKE SA. To znaczy, że jedna wymiana może zawieść w dwóch bardzo różnych miejscach: w tożsamości albo w polityce. Czytaj ładunek powiadomienia lub błąd, a nie ogólne niepowodzenie uzgadniania, bo rozwiązaniem jednego jest certyfikat, a drugiego niezgodność podsieci.
Dwa SA, dwa zadania
| Stowarzyszenie | Chroni | Zachowanie czasu życia |
|---|---|---|
| IKE SA | Wymiany zarządzające: odnowienie kluczy, usuwanie, ładunki konfiguracji | Odświeżane według własnego harmonogramu; ścieżka danych może przetrwać zmianę |
| CHILD SA | Ruch aplikacji pasujący do selektorów ruchu | Odświeżane niezależnie, często częściej |
Trzymanie ich osobno wyjaśnia dwa zachowania, które wyglądają jak błędy. Tunel może wyglądać na ustanowiony, gdy w tle zawodzi odnowienie kluczy, a CHILD SA można wymienić bez utraty połączenia przez klienta.
W strongSwan dokumentacja konfiguracji IKEv2 i swanctl --list-sas pokazują oba poziomy, a ip xfrm state oraz ip xfrm policy pokazują, co jądro naprawdę zainstalowało. Porównanie tych dwóch widoków to najszybszy sposób, by zobaczyć, czy negocjacja się zakończyła, czy tylko na to wyglądała. Jeśli demon wymienia CHILD SA, dla którego jądro nie ma stanu, instalacja po cichu się nie powiodła. Jeśli jądro trzyma stan, którego demon nie zna, patrzysz na pozostałość wcześniejszej próby.
Co jeszcze musi być prawdą po podniesieniu tunelu
Selektory ruchu określają, które adresy są objęte. Jeśli klient proponuje jedną podsieć, a serwer oczekuje innej, CHILD SA instaluje się, ale nie przenosi nic użytecznego, a błąd wygląda na problem routingu, nie negocjacji. Potem stos lokalny musi współpracować: przekazywanie włączone tam, gdzie host routuje, trasy wskazujące tunel, reguły zapory przepuszczające odhermetyzowane pakiety i wewnętrzny resolver, jeśli w grę wchodzą prywatne nazwy. Każdy z tych elementów zawodzi osobno i żadnego nie naprawia restart demona IKE.
Trzymaj dziennik widoczny podczas diagnozy: wymiana początkowa, potem walidacja tożsamości, następnie uwierzytelnianie użytkownika, gdzie ma zastosowanie, potem instalacja CHILD, a na końcu ruch aplikacji. Etap, który się zatrzymuje, jest etapem do naprawy, a późniejszy błąd routingu nigdy nie jest powodem, by poluzować już zdane kontrole tożsamości.