Wychodzący ESP bez odpowiedzi nie oznacza, że VPN jest martwy
ESP chroni jeden kierunek na asocjację i niczego nie potwierdza. Zestaw wewnętrzną rozmowę z SA przychodzącą, zanim nazwiesz serwer nieodpowiadającym.
Przechwyciłeś ruch na hoście IPsec, widziałeś pakiety ESP wychodzące, nie zobaczyłeś nic wracającego i wywnioskowałeś, że druga strona jest zepsuta. Przechwycenie nie wspiera tego wniosku. ESP chroni jeden kierunek rozmowy i niczego nie potwierdza na poziomie IP, więc brakujące ESP powrotne może oznaczać, że aplikacja nie miała nic do powiedzenia, równie dobrze jak to, że tunel jest martwy. Przeczytaj wewnętrzną wymianę i stan po stronie odbiorczej, zanim obwinisz którykolwiek koniec.
Mit: każdy chroniony pakiet zasługuje na odpowiedź
ESP nie jest protokołem żądanie-odpowiedź. Szyfruje i uwierzytelnia to, co wybierze polityka, a odbiorca waliduje, odszyfrowuje i dostarcza ten wewnętrzny pakiet, nie generując własnego. Zapytanie UDP, które cel ignoruje, albo echo ICMP, które polityka przychodząca odrzuca, w obu kierunkach daje ciszę jako prawidłowy wynik. Traktowanie tej ciszy jako awarii transportu wysyła cię na poszukiwanie usterki sieci, której nigdy nie było.
Jednokierunkowe przechwycenie faktycznie dowodzi, że stos nadawcy coś zaszyfrował w tym punkcie obserwacji. Niczego o dotarciu i niczego o zamiarze odpowiedzi. Użyteczne pytanie brzmi nie „dlaczego nie ma odpowiedzi“, lecz „co powinna była wytworzyć wewnętrzna rozmowa“.
Dwie SA, dwa SPI, jedna rozmowa
Asocjacje bezpieczeństwa IPsec są jednokierunkowe, więc normalna chroniona wymiana prowadzi asocjację przychodzącą i asocjację wychodzącą z osobnymi identyfikatorami i niezależnym stanem. Szukanie ruchu powrotnego po SPI pakietu wychodzącego jest więc błędem kategorii, ponieważ każda odpowiedź wędruje pod własną asocjacją wychodzącą partnera z jego własnym SPI. Zamiast tego dopasuj parę po selektorach ruchu i adresach partnera.
Ponowne ustalanie klucza komplikuje obraz na kilka sekund, ponieważ stary i zastępczy stan mogą się nakładać. Jeśli objaw zaczął się wokół zmiany klucza, zbierz identyfikatory asocjacji i znaczniki czasu razem, a nie tylko nazwę połączenia.
Co odbiorca musi zrobić, zanim cokolwiek odpowie
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Każdy wiersz zawodzi niezależnie i każda awaria ma innego właściciela, dlatego jedno przechwycenie nie potrafi ich rozróżnić. Licznik przychodzący to jedyny bezpośredni dowód dotarcia, ponieważ pakiet, który nie przejdzie uwierzytelnienia lub kontroli powtórzeń, jest odrzucany bez żadnej odpowiedzi. Partner, którego licznik przychodzący się nie poruszył, nie przekazuje ci więc żadnej informacji o swojej polityce.
Dostarczenie to osobny krok od odszyfrowania. Stan może być prawidłowy, a pakiet mimo to odrzucony później przez politykę przychodzącą lub trasę, która nie obejmuje wewnętrznego celu, więc sprawdź, czy docelowy host widział czysty tekst, zamiast zakładać, że czysty licznik oznacza, iż pakiet dotarł tam, gdzie chciałeś.
Rodzimy ESP to nie UDP
Rodzimy ESP to protokół IP 50, który nie jest ani TCP, ani UDP i nie ma żadnych portów. Reguła zapory zezwalająca na IKE na UDP 500 nie mówi więc nic o ścieżce danych, a filtr napisany wokół portów może pozwolić tunelowi wynegocjować, a potem porzucić wszystko, co jest w nim przenoszone. Przetestuj ścieżkę danych osobno, w trybie, który faktycznie obserwowałeś.
Za NAT kształt się zmienia: chroniony ładunek podróżuje wewnątrz UDP, zwykle na porcie 4500, jak definiuje RFC 3948. Zarejestruj aktywny tryb przed napisaniem jakiejkolwiek reguły, ponieważ urządzenie na ścieżce może traktować rodzimy ESP i ESP enkapsulowane w UDP zupełnie inaczej, a niektóre urządzenia pośredniczące przepuszczają jedno, odrzucając drugie.
Czytaj liczniki należące do tego zdarzenia
Na hoście strongSwan swanctl --list-sas raportuje liczniki pakietów i bajtów dla każdej asocjacji w obu kierunkach, co wystarcza, by odróżnić „nigdy nie dotarło“ od „dotarło i nie odpowiedziano“. W systemie Linux /proc/net/xfrm_stat zlicza zbiorcze błędy, takie jak brakujący stan, brakująca polityka i błędy protokołu. Te sumy narastają od rozruchu i należą do jednej przestrzeni nazw sieci, więc duża liczba nie jest przypisaniem.
Weź dwa odczyty wokół okna zdarzenia we właściwej przestrzeni nazw i porównaj różnice, inaczej przypiszesz zeszłotygodniowe błędy do dzisiejszego zgłoszenia. Umieść przestrzeń nazw i oba znaczniki czasu w zgłoszeniu, aby następny czytelnik mógł odtworzyć porównanie, zamiast ufać sumie.
Nazwij etap, nie podejrzanego
Użyteczny wniosek mówi, gdzie pakiet się zatrzymał: nigdy nie odebrany, odebrany i odrzucony, dostarczony, ale bez odpowiedzi, albo odpowiedziano i zgubiony w drodze powrotnej. Każdy z tych przypadków wskazuje innego właściciela i inne następne polecenie. „Brak odpowiedzi z serwera VPN“ spłaszcza cztery różne usterki do jednego zdania, którego przechwycenie nigdy nie uzasadniało.
Utrzymuj przechwycenia wąskie i nie umieszczaj surowego stanu jądra w zgłoszeniach, ponieważ może zawierać materiał klucza, który nie powinien opuszczać hosta. Różnice liczników i znaczniki czasu to części warte przekazania następnej osobie.