Waarom IKEv2 op Android mislukt op een niet-standaard UDP-poort

Een native IKEv2-formulier neemt een adres, geen poort. Controleer of de client dit ondersteunt, stel beide serverpoorten in en kijk daarna naar de framing en de logboeken.

De gateway antwoordt op UDP 4443 op IKEv2 met een reden, het profiel heeft een veld met de naam Server, u typt de hostnaam en de poort, en de telefoon meldt dat hij de server niet kan bereiken of het adres niet kan omzetten. Er wordt niets geblokkeerd. Het native Android-formulier verwacht een host, en hetzelfde geldt op Windows. Een aangepaste poort is een clientmogelijkheid voordat het een serverinstelling is, en alleen sommige clients laten u die uitdrukken. Loop de drie delen op volgorde door: wat de client kan zeggen, waarop de server luistert en of beide kanten de pakketten op dezelfde manier framen.

Wat de telefoon werkelijk verstuurde

Een host:port-tekenreeks in een veld dat voor een naam bedoeld is, wordt als naam omgezet. De resolver geeft niets terug voor vpn.example.net:4443, en de fout die u ziet is een naamomzettings- of onbereikbaarheidsfout, niet een time-out op een poort. Dat onderscheid is belangrijk, want opnieuw proberen met een kortere naam of een ander netwerk zal een tekenreeks die het formulier niet kan verwerken nooit repareren.

Het native IKEv2-profiel op Android is, net als de ingebouwde Windows VPN-client, vastgezet op de standaard IKE-poorten. Geen van beide toont een poortveld, en geen profielbewerking voegt er een toe. Als de listener van de operator werkelijk op 4443 staat, is de ingebouwde client het verkeerde gereedschap, niet een verkeerd geconfigureerd.

Gebruik een client die de poort toont

De strongSwan-client voor Android documenteert een configureerbare serverpoort in de geavanceerde profielinstellingen, daarom komt hij in bijna elk werkend recept voor dit ontwerp voor. Die ondersteuning hoort bij die client: een andere IKEv2-app, of een leveranciersfork van dezelfde app, toont hetzelfde veld misschien niet, ook al ondersteunt de onderliggende strongSwan-daemon het.

Vraag de operator om de hele set in één keer: gatewaynaam, UDP-poort, authenticatiemethode en de serveridentiteit die de client moet verwachten. Een aangepaste poort is geen reden om certificaatcontrole uit te schakelen of protocollen te wisselen. Voer de poort in waar de geïnstalleerde client hem verwacht, en als die client zo'n veld niet heeft, is het antwoord een andere goedgekeurde client en niet een geraden omweg.

De server heeft twee poorten, en beide moeten overeenkomen

IKE begint op UDP 500, en NAT-traversal verplaatst IKE en ingekapselde ESP meestal naar UDP 4500. Dat zijn aparte instellingen in strongSwan, dus een server die naar één aangepaste poort is verplaatst, moet beide op dezelfde waarde zetten:

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

Met één poort voor beide rollen moet de daemon IKE onderscheiden van ESP-in-UDP op dezelfde socket, wat hij doet via de vier-byte-markering die geen ESP is en die aan een IKE-bericht voorafgaat. Daarom kan een client niet onderhandelen op de aangepaste poort en daarna stil doorgaan op 4500, en daarom verbergt de zin ‘verander gewoon de poort’ een framingvereiste.

Een doorsturing is geen listener

Het doorsturen van 4443 naar een gewone IKE-listener is de faalmodus die er bijna geslaagd uitziet. De eerste uitwisseling komt aan, de server antwoordt, en dan stokt de verbinding of sleutelt hij opnieuw naar niets, omdat het antwoord van een andere poort vertrekt en het latere ingekapselde verkeer nooit overeenkomt met de toestand die beide kanten hebben opgebouwd. Een regel die de doelpoort herschrijft zonder de listener te verplaatsen, levert precies dit halfopen resultaat op.

Het pad moet ook UDP van begin tot eind toestaan. Dat TCP 443 door een hotel- of operatornetwerk komt, zegt niets over IKEv2 op een UDP-poort, zelfs niet met hetzelfde nummer. Waar alleen TCP 443 is toegestaan, maakt een aangepaste UDP-poort van IKEv2 geen HTTPS, en het juiste antwoord kan een ander toegangspad zijn in plaats van nog een poortexperiment.

Scheid de drie fasen bij het testen

Leg vast op de server terwijl de client het één keer probeert. Een verzoek dat nooit aankomt is een kwestie van eindpunt of firewall; een verzoek dat zonder antwoord aankomt is een kwestie van listener of beleid; een antwoord waarop stilte volgt is de kwestie van framing of identiteit.

tcpdump -ni eth0 -vv udp port 4443

Lees daarna het bericht van de client in plaats van zijn draaiende indicator. Een voorstelfout betekent dat de algoritmen niet overeenkomen, een authenticatiefout betekent dat identiteiten of certificaten niet overeenkomen, en herhaalde verzendingen zonder antwoord betekenen dat er niets op die poort antwoordt. Test één fase tegelijk en wijzig één veld tussen pogingen; de strongSwan-documentatie over NAT-traversal beschrijft de markering en het poortgedrag dat de opname u toont.

Gerelateerde artikelen