Varför IKEv2 på Android misslyckas på en icke-standard UDP-port

Ett inbyggt IKEv2-formulär tar en adress, inte en port. Bekräfta att klienten stöder det, ställ in båda serverportarna och titta sedan på ramningen och loggarna.

Gatewayen svarar på IKEv2 på UDP 4443 av en anledning, profilen har ett fält som heter Server, du skriver in värdnamnet och porten, och telefonen rapporterar att den inte når servern eller inte kan slå upp adressen. Ingenting blockeras. Det inbyggda Android-formuläret förväntar sig en värd, och detsamma gäller i Windows. En egen port är en klientegenskap innan den är en serverinställning, och bara vissa klienter låter dig uttrycka den. Gå igenom de tre delarna i ordning: vad klienten kan säga, vad servern lyssnar på och om båda ändarna ramar in paketen på samma sätt.

Vad telefonen faktiskt skickade

En värd:port-sträng i ett fält avsett för ett namn slås upp som ett namn. Uppslagaren returnerar ingenting för vpn.example.net:4443, och felet du ser är ett namnuppslagnings- eller otillgänglighetsfel, inte en tidsgräns på en port. Den skillnaden spelar roll, eftersom ett nytt försök med ett kortare namn eller ett annat nätverk aldrig reparerar en sträng som formuläret inte kan tolka.

Den inbyggda IKEv2-profilen på Android är, liksom den inbyggda Windows VPN-klienten, låst till standard-IKE-portarna. Ingen av dem visar ett portfält, och ingen profilredigering lägger till ett. Om operatörens lyssnare verkligen ligger på 4443 är den inbyggda klienten fel verktyg, inte ett felkonfigurerat.

Använd en klient som visar porten

strongSwan-klienten för Android dokumenterar en konfigurerbar serverport i de avancerade profilinställningarna, därför dyker den upp i nästan varje fungerande recept för den här designen. Det stödet tillhör den klienten: en annan IKEv2-app, eller en leverantörsfork av samma app, visar kanske inte samma fält även om den underliggande strongSwan-demonen stöder det.

Be operatören om hela uppsättningen på en gång: gatewaynamn, UDP-port, autentiseringsmetod och den serveridentitet som klienten måste förvänta sig. En egen port är inte skäl att stänga av certifikatkontrollen eller byta protokoll. Ange porten där den installerade klienten förväntar sig den, och om den klienten inte har ett sådant fält är svaret en annan godkänd klient och inte en gissad omväg.

Servern har två portar, och båda måste stämma

IKE börjar på UDP 500, och NAT-traversering flyttar vanligtvis IKE och inkapslad ESP till UDP 4500. Det är separata inställningar i strongSwan, så en server som flyttats till en enda egen port måste ändra båda till samma värde:

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

Med en port för båda rollerna måste demonen skilja IKE från ESP-i-UDP på samma socket, vilket den gör med den fyra byte långa markören som inte är ESP och som föregår ett IKE-meddelande. Därför kan en klient inte förhandla på den egna porten och sedan tyst fortsätta på 4500, och därför döljer frasen ”byt bara porten” ett krav på ramning.

En vidarebefordran är inte en lyssnare

Vidarebefordran av 4443 till en vanlig IKE-lyssnare är felläget som ser nästan lyckat ut. Det första utbytet anländer, servern svarar, och sedan stannar anslutningen eller förnyar nycklar till ingenting, eftersom svaret går ut från en annan port och den senare inkapslade trafiken aldrig stämmer med det tillstånd som de två ändarna skapade. En regel som skriver om målporten utan att flytta lyssnaren ger exakt detta halvöppna resultat.

Vägen måste också tillåta UDP från ände till ände. Att TCP 443 tar sig igenom ett hotell- eller operatörsnät säger ingenting om IKEv2 på en UDP-port, inte ens med samma nummer. Där bara TCP 443 tillåts gör en egen UDP-port inte IKEv2 till HTTPS, och det rätta svaret kan vara en annan åtkomstväg i stället för ännu ett portexperiment.

Separera de tre faserna när du testar

Fånga på servern medan klienten försöker en gång. En begäran som aldrig anländer är en fråga om ändpunkt eller brandvägg; en begäran som anländer utan svar är en fråga om lyssnare eller policy; ett svar som följs av tystnad är frågan om ramning eller identitet.

tcpdump -ni eth0 -vv udp port 4443

Läs sedan klientens meddelande i stället för dess snurrande indikator. Ett förslagsfel betyder att algoritmerna inte stämmer, ett autentiseringsfel betyder att identiteter eller certifikat inte stämmer, och upprepade omsändningar utan svar betyder att ingenting svarar på den porten. Testa en fas i taget och ändra ett fält mellan försöken; strongSwan-dokumentationen om NAT-traversering beskriver markören och portbeteendet som fångsten visar dig.

Relaterade artiklar