Hvorfor IKEv2 på Android fejler på en ikke-standard UDP-port

En indbygget IKEv2-formular tager en adresse, ikke en port. Bekræft, at klienten understøtter det, sæt begge serverporte, og se så på framing og logfiler.

Gatewayen svarer på IKEv2 på UDP 4443 af en grund, profilen har et felt med navnet Server, du skriver værtsnavn og port, og telefonen rapporterer, at den ikke kan nå serveren eller ikke kan slå adressen op. Intet bliver blokeret. Den indbyggede Android-formular forventer en vært, og det samme gælder på Windows. En brugerdefineret port er en klientkapacitet, før den er en serverindstilling, og kun nogle klienter lader dig udtrykke den. Gå de tre dele igennem i rækkefølge: hvad klienten kan sige, hvad serveren lytter på, og om begge ender indrammer pakkerne på samme måde.

Hvad telefonen faktisk sendte

En vært:port-streng i et felt beregnet til et navn bliver slået op som et navn. Resolveren returnerer intet for vpn.example.net:4443, og den fejl, du ser, er en navneopløsnings- eller utilgængelighedsfejl og ikke en timeout på en port. Den forskel betyder noget, fordi et nyt forsøg med et kortere navn eller et andet netværk aldrig vil rette en streng, som formularen ikke kan fortolke.

Den indbyggede IKEv2-profil på Android er ligesom den indbyggede Windows VPN-klient låst til de standardmæssige IKE-porte. Ingen af dem viser et portfelt, og ingen mængde profilredigering tilføjer et. Hvis operatørens listener virkelig er på 4443, er den indbyggede klient det forkerte værktøj og ikke et fejlkonfigureret et.

Brug en klient, der viser porten

strongSwan-klienten til Android dokumenterer en konfigurerbar serverport i de avancerede profilindstillinger, og derfor optræder den i næsten enhver fungerende opskrift til dette design. Den understøttelse tilhører den klient: en anden IKEv2-app eller en leverandørfork af samme app viser måske ikke det samme felt, selv om den underliggende strongSwan-dæmon understøtter det.

Bed operatøren om hele sættet på én gang: gatewaynavn, UDP-port, godkendelsesmetode og den serveridentitet, klienten skal forvente. En brugerdefineret port er ikke grund til at slå certifikatkontrol fra eller skifte protokol. Indtast porten, hvor den installerede klient forventer den, og hvis den klient ikke har et sådant felt, er svaret en anden godkendt klient og ikke en gættet omvej.

Serveren har to porte, og begge skal matche

IKE starter på UDP 500, og NAT-gennemføring flytter normalt IKE og indkapslet ESP til UDP 4500. Det er separate indstillinger i strongSwan, så en server, der er flyttet til en enkelt brugerdefineret port, skal ændre begge til samme værdi:

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

Med én port til begge roller skal dæmonen skelne IKE fra ESP-i-UDP på samme socket, hvilket den gør ved hjælp af den fire-byte-markør, der ikke er ESP, og som går forud for en IKE-besked. Derfor kan en klient ikke forhandle på den brugerdefinerede port og derefter stille fortsætte på 4500, og derfor skjuler sætningen “skift bare porten” et krav om framing.

En videresendelse er ikke en listener

Videresendelse af 4443 til en almindelig IKE-listener er den fejltilstand, der ser næsten vellykket ud. Den første udveksling ankommer, serveren svarer, og forbindelsen går så i stå eller gennøgler til ingenting, fordi svaret forlader en anden port, og den senere indkapslede trafik aldrig matcher den tilstand, de to ender har oprettet. En regel, der omskriver destinationsporten uden at flytte listeneren, giver præcis dette halvåbne resultat.

Vejen skal også tillade UDP fra ende til ende. At TCP 443 slipper gennem et hotel- eller operatørnetværk siger intet om IKEv2 på en UDP-port, ikke engang en med samme nummer. Hvor kun TCP 443 er tilladt, gør en brugerdefineret UDP-port ikke IKEv2 til HTTPS, og det rigtige svar kan være en anden adgangsvej i stedet for endnu et porteksperiment.

Adskil de tre faser, når du tester

Optag på serveren, mens klienten forsøger én gang. En anmodning, der aldrig ankommer, er et spørgsmål om endepunkt eller firewall; en anmodning, der ankommer uden svar, er et spørgsmål om listener eller politik; et svar, der efterfølges af tavshed, er spørgsmålet om framing eller identitet.

tcpdump -ni eth0 -vv udp port 4443

Læs derefter klientens besked i stedet for dens snurrende indikator. En forslagsfejl betyder, at algoritmerne ikke er enige, en godkendelsesfejl betyder, at identiteter eller certifikater ikke er enige, og gentagne gensendelser uden svar betyder, at intet svarer på den port. Test én fase ad gangen, og skift ét felt mellem forsøgene; strongSwans dokumentation om NAT-gennemføring beskriver den markør og den portadfærd, som optagelsen viser dig.

Relaterede artikler