Proč IKEv2 na Androidu nefunguje na nestandardním UDP portu

Nativní formulář IKEv2 bere adresu, ne port. Ověřte, že to klient podporuje, nastavte oba porty serveru a pak se podívejte na rámování a logy.

Brána odpovídá na IKEv2 na UDP 4443 z nějakého důvodu, profil má pole označené Server, zadáte název hostitele a port a telefon hlásí, že se k serveru nedostane nebo že nedokáže přeložit adresu. Nic se neblokuje. Nativní formulář na Androidu očekává hostitele a totéž platí ve Windows. Vlastní port je schopnost klienta dřív, než je nastavením serveru, a jen některé klienty vám ho dovolí vyjádřit. Projděte tři části popořadě: co klient umí říct, na čem server poslouchá a zda oba konce rámují pakety stejně.

Co telefon skutečně odeslal

Řetězec host:port v poli určeném pro jméno se přeloží jako jméno. Překladač nevrátí pro vpn.example.net:4443 nic a chyba, kterou vidíte, je selhání překladu jména nebo nedostupnosti, ne vypršení časového limitu na portu. Na tom rozdílu záleží, protože opakování s kratším jménem nebo jinou sítí nikdy neopraví řetězec, který formulář neumí zpracovat.

Nativní profil IKEv2 na Androidu je stejně jako vestavěný klient Windows VPN pevně svázán se standardními porty IKE. Ani jeden nevykazuje pole portu a žádné úpravy profilu ho nepřidají. Pokud posluchač operátora skutečně běží na 4443, je vestavěný klient špatný nástroj, ne špatně nastavený.

Použijte klienta, který port vykazuje

Klient strongSwan pro Android dokumentuje konfigurovatelný port serveru v pokročilém nastavení profilu, a proto se objevuje téměř v každém funkčním receptu na tento návrh. Tato podpora patří tomu klientovi: jiná aplikace IKEv2 nebo dodavatelská odnož téže aplikace nemusí stejné pole vykazovat, i když to základní démon strongSwan podporuje.

Vyžádejte od operátora celou sadu najednou: název brány, port UDP, metodu ověření a identitu serveru, kterou má klient očekávat. Vlastní port není důvod vypnout kontrolu certifikátů nebo změnit protokoly. Zadejte port tam, kde ho nainstalovaný klient očekává, a pokud takové pole nemá, odpovědí je jiný schválený klient, ne odhadnutá oklika.

Server má dva porty a oba musí souhlasit

IKE začíná na UDP 500 a průchod NAT obvykle přesouvá IKE a zapouzdřený ESP na UDP 4500. V strongSwanu jde o samostatná nastavení, takže server přesunutý na jediný vlastní port musí oba změnit na stejnou hodnotu:

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

Když jeden port slouží oběma rolím, musí démon na témže socketu rozlišit IKE od ESP v UDP, což dělá pomocí čtyřbajtového markeru, který není ESP a předchází zprávě IKE. Proto klient nemůže vyjednávat na vlastním portu a pak tiše pokračovat na 4500, a proto fráze “stačí změnit port” skrývá požadavek na rámování.

Přesměrování není posluchač

Přesměrování 4443 na běžný posluchač IKE je režim selhání, který vypadá téměř úspěšně. První výměna dorazí, server odpoví a spojení se pak zasekne nebo přegeneruje klíče do nicoty, protože odpověď vychází z jiného portu a pozdější zapouzdřený provoz nikdy neodpovídá stavu, který oba konce vytvořily. Pravidlo, které přepisuje cílový port bez přesunutí posluchače, dává přesně tento polootevřený výsledek.

Cesta musí také povolit UDP od konce ke konci. Průchod TCP 443 přes hotelovou nebo operátorskou síť neříká o IKEv2 na UDP portu nic, ani když má stejné číslo. Tam, kde je povolen jen TCP 443, vlastní UDP port neudělá z IKEv2 HTTPS a správnou odpovědí může být jiná přístupová cesta, ne další experiment s portem.

Při testování oddělte tři fáze

Zachyťte provoz na serveru, zatímco se klient pokusí jednou. Požadavek, který nikdy nedorazí, je otázka koncového bodu nebo firewallu; požadavek, který dorazí bez odpovědi, je otázka posluchače nebo zásad; odpověď, po níž následuje ticho, je otázka rámování nebo identity.

tcpdump -ni eth0 -vv udp port 4443

Pak čtěte zprávu klienta, ne jeho točící se indikátor. Chyba návrhu znamená, že se algoritmy neshodují, selhání ověření znamená, že se neshodují identity nebo certifikáty, a opakované přenosy bez odpovědi znamenají, že na tom portu nic neodpovídá. Testujte jednu fázi po druhé a mezi pokusy měňte jedno pole; dokumentace strongSwanu k průchodu NAT popisuje marker a chování portu, které vám zachycený provoz ukazuje.

Související články