IKEv2 używa UDP 500 i 4500: który z nich przenosi dane?

Pierwsza wymiana i ścieżka przenosząca dane to nie ten sam strumień. Sprawdź oba porty i pamiętaj, że natywny ESP to numer protokołu, a nie port.

Otwarcie UDP 500 w zaporze pozwala tunelowi negocjować, a potem połączenie przestaje przepuszczać ruch. Lista portów była niepełna, a nie błędna. IKEv2 zaczyna na jednym sockecie i w wielu rzeczywistych wdrożeniach kontynuuje na innym, a ładunek może wcale nie być portem. Czytanie etapów po kolei wyjaśnia, której reguły brakuje.

Dwa porty, dwa zadania

IKEv2 zaczyna od wymiany kluczy na UDP 500, gdzie strony uwierzytelniają się i ustanawiają asocjację bezpieczeństwa dla tunelu. Ścieżka danych, która następuje, to osobna sprawa: może to być natywny ESP, czyli numer protokołu IP, a nie port, albo ruch hermetyzowany w UDP na 4500. Rozdzielenie tych dwóch w przeglądzie zapory to różnica między tunelem, który negocjuje, a tunelem, który działa. Jeden socket przenosi sterowanie, drugi ładunek.

Dlatego reguła dopuszczająca tylko 500 daje najbardziej mylący objaw w całej rodzinie protokołów: negocjacja się udaje i nic pożytecznego nie następuje. Stan pokazuje drugą stronę, dziennik pokazuje ustanowioną IKE SA, a aplikacja nadal kończy się przekroczeniem czasu. Brakujące pozwolenie należy do innego strumienia niż ten, który właśnie się powiódł.

Dlaczego 4500 w ogóle istnieje

Wiele urządzeń NAT nie potrafi przekazywać protokołu innego niż TCP lub UDP, a niektóre przepisują adresy w sposób, który psuje kontrolę integralności ESP. Hermetyzacja ESP w UDP rozwiązuje oba problemy, kosztem dodatkowego nagłówka i drugiego portu, który trzeba dopuścić. Właśnie ta hermetyzacja jest powodem istnienia drugiego portu.

Gdy NAT zostanie wykryty, sam IKE również przenosi się na 4500, aby cały ruch dzielił jedną ścieżkę przez translator. Czterobajtowy znacznik, który nie jest ESP, odróżnia komunikaty sterujące od danych na tym sockecie. Ta zmiana to decyzja protokołu, a nie preferencja administratora.

Gdzie zmienia się port źródłowy

Translator może przepisać port źródłowy klienta, więc krotka widziana na serwerze nie zgadza się z krotką na kliencie. Sprawdź obie strony każdego skoku NAT, zanim uznasz, że reguła jest ignorowana. Diagnostyka tylko na kliencie może dać regułę, która wygląda poprawnie i mimo to zawodzi.

Implementacje zgodne z MOBIKE mogą też przejść na 4500 bez wykrytego NAT, a niektóre wdrożenia celowo wymuszają tę ścieżkę. Widok 4500 jest więc dowodem decyzji, a nie dowodem domowego routera.

Sprawdź oba strumienie na każdej granicy

Przejdź przez trzy granice: sieć klienta, dowolną zaporę pośrednią i serwer. Każda potrzebuje strumieni udokumentowanych przez wdrożenie, a nie strumieni z artykułu o innym przypadku.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Wiersz ESP na liście zapory to dopasowanie protokołu, więc reguła portu nigdy go nie obejmuje. Jeśli operator używa niestandardowego portu, postępuj zgodnie z udokumentowaną konfiguracją na obu końcach, ponieważ klient nie może utworzyć nasłuchu na serwerze przez wybranie znanego numeru.

Zapisz, gdzie zatrzymała się negocjacja i czy zainstalowano podrzędną asocjację bezpieczeństwa, ponieważ ta para oddziela zablokowaną ścieżkę od błędu uwierzytelniania lub polityki. Następnie powtórz test z włączoną weryfikacją serwera, ponieważ osiągalność nie jest uwierzytelnianiem. Ten ostatni krok oddziela dozwolony port od zaufanej strony.

Powiązane artykuły