Dlaczego IKEv2 na Androidzie zawodzi na niestandardowym porcie UDP

Natywny formularz IKEv2 przyjmuje adres, a nie port. Potwierdź, że klient to obsługuje, ustaw oba porty serwera, a następnie sprawdź ramkowanie i logi.

Brama odpowiada na IKEv2 na UDP 4443 z jakiegoś powodu, profil ma pole o nazwie Server, wpisujesz nazwę hosta i port, a telefon zgłasza, że nie może dotrzeć do serwera albo nie potrafi rozwiązać adresu. Nic nie jest blokowane. Natywny formularz Androida oczekuje hosta, i to samo dotyczy Windows. Niestandardowy port jest możliwością klienta, zanim staje się ustawieniem serwera, i tylko niektóre klienty pozwalają ją wyrazić. Przejdź przez trzy części po kolei: co klient może powiedzieć, na czym nasłuchuje serwer i czy oba końce ramkują pakiety w ten sam sposób.

Co telefon faktycznie wysłał

Łańcuch host:port w polu przeznaczonym na nazwę jest rozwiązywany jako nazwa. Resolver nic nie zwraca dla vpn.example.net:4443, a błąd, który widzisz, to nie przekroczenie czasu na porcie, lecz błąd rozwiązywania nazwy lub nieosiągalności. Ta różnica ma znaczenie, bo ponowna próba z krótszą nazwą lub inną siecią nigdy nie naprawi łańcucha, którego formularz nie potrafi przeanalizować.

Natywny profil IKEv2 na Androidzie, podobnie jak wbudowany klient VPN Windows, jest przypisany do standardowych portów IKE. Żaden z nich nie pokazuje pola portu, a żadna edycja profilu go nie dodaje. Jeśli nasłuch operatora naprawdę działa na 4443, wbudowany klient jest niewłaściwym narzędziem, a nie błędnie skonfigurowanym.

Użyj klienta, który pokazuje port

Klient strongSwan dla Androida dokumentuje konfigurowalny port serwera w zaawansowanych ustawieniach profilu, dlatego pojawia się w prawie każdym działającym przepisie na to rozwiązanie. To wsparcie należy do tego klienta: inna aplikacja IKEv2 albo fork dostawcy tej samej aplikacji może nie pokazywać tego samego pola, nawet jeśli bazowy demon strongSwan je obsługuje.

Poproś operatora o cały zestaw naraz: nazwę bramy, port UDP, metodę uwierzytelniania i tożsamość serwera, której klient ma oczekiwać. Niestandardowy port nie jest powodem do wyłączania sprawdzania certyfikatów ani zmiany protokołów. Wpisz port tam, gdzie oczekuje go zainstalowany klient, a jeśli ten klient nie ma takiego pola, odpowiedzią jest inny zatwierdzony klient, a nie zgadywane obejście.

Serwer ma dwa porty i oba muszą się zgadzać

IKE zaczyna na UDP 500, a przechodzenie NAT zwykle przenosi IKE i hermetyzowany ESP na UDP 4500. To osobne ustawienia w strongSwan, więc serwer przeniesiony na jeden niestandardowy port musi zmienić oba na tę samą wartość:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Gdy jeden port obsługuje obie role, demon musi odróżnić IKE od ESP-w-UDP na tym samym gnieździe, co robi czterobajtowym znacznikiem nie-ESP, który poprzedza komunikat IKE. Dlatego klient nie może negocjować na niestandardowym porcie, a potem po cichu kontynuować na 4500, i dlatego zdanie „po prostu zmień port” ukrywa wymóg ramkowania.

Przekierowanie to nie nasłuch

Przekierowanie 4443 do zwykłego nasłuchu IKE to tryb awarii, który wygląda prawie na sukces. Pierwsza wymiana dociera, serwer odpowiada, a potem połączenie zastyga albo od nowa generuje klucze donikąd, bo odpowiedź wychodzi z innego portu, a późniejszy hermetyzowany ruch nigdy nie pasuje do stanu, który utworzyły oba końce. Reguła, która przepisuje port docelowy bez przenoszenia nasłuchu, daje dokładnie ten na wpół otwarty wynik.

Ścieżka musi też dopuszczać UDP od końca do końca. To, że TCP 443 przechodzi przez sieć hotelową lub operatora, nic nie mówi o IKEv2 na porcie UDP, nawet o tym samym numerze. Tam, gdzie dozwolony jest tylko TCP 443, niestandardowy port UDP nie zamienia IKEv2 w HTTPS, a właściwą odpowiedzią może być inna ścieżka dostępu, a nie kolejny eksperyment z portem.

Podczas testów rozdziel trzy etapy

Przechwyć ruch na serwerze, gdy klient próbuje raz. Żądanie, które nigdy nie dociera, to kwestia punktu końcowego lub zapory; żądanie, które dociera bez odpowiedzi, to kwestia nasłuchu lub polityki; odpowiedź, po której następuje cisza, to kwestia ramkowania lub tożsamości.

tcpdump -ni eth0 -vv udp port 4443

Następnie czytaj komunikat klienta, a nie jego wirujący wskaźnik. Błąd propozycji oznacza, że algorytmy się nie zgadzają, błąd uwierzytelniania oznacza, że tożsamości lub certyfikaty się nie zgadzają, a powtarzane retransmisje bez odpowiedzi oznaczają, że nic nie odpowiada na tym porcie. Testuj jeden etap naraz i zmieniaj jedno pole między próbami; dokumentacja strongSwan o przechodzeniu NAT opisuje znacznik i zachowanie portu, które pokazuje ci przechwycony ruch.

Powiązane artykuły