Kvifor IKEv2 på Android feilar på ein ikkje-standard UDP-port

Gatewayen svarar på IKEv2 på UDP 4443 av ein grunn, profilen har eit felt kalla Server, du skriv inn vertsnamnet og porten, og telefonen melder at han ikkje når serveren eller ikkje kan slå opp adressa. Ingenting vert blokkert. Det innebygde Android-skjemaet ventar ein vert, og det same gjeld i Windows. Ein eigen port er ein klientegenskap før han er ei serverinnstilling, og berre nokre klientar lèt deg uttrykkje han. Gå gjennom dei tre delane i rekkefølgje: kva klienten kan seie, kva serveren lyttar på, og om begge endar rammar inn pakkane på same måte.

Kva telefonen faktisk sende

Ein vert:port-streng i eit felt som er meint for eit namn, vert løyst opp som eit namn. Oppløysaren returnerer ingenting for vpn.example.net:4443, og feilen du ser er ein namneoppløysings- eller utilgjengelegfeil, ikkje ein tidsavbrot på ein port. Den skilnaden har noko å seie, fordi eit nytt forsøk med eit kortare namn eller eit anna nettverk aldri vil reparere ein streng som skjemaet ikkje kan tolke.

Den innebygde IKEv2-profilen på Android er, som den innebygde Windows VPN-klienten, låst til dei standard IKE-portane. Ingen av dei viser eit portfelt, og inga profilredigering legg til eitt. Viss lyttaren til operatøren faktisk er på 4443, er den innebygde klienten feil verkty, ikkje eit feilkonfigurert eit.

Bruk ein klient som viser porten

strongSwan-klienten for Android dokumenterer ein konfigurerbar serverport i dei avanserte profilinnstillingane, og difor dukkar han opp i nesten kvar oppskrift som fungerer for dette designet. Den støtta høyrer til den klienten: ein annan IKEv2-app, eller ein leverandørgaffel av same app, viser kanskje ikkje det same feltet sjølv om den underliggjande strongSwan-demonen støttar det.

Be operatøren om heile settet på ein gong: gatewaynamn, UDP-port, autentiseringsmetode og serveridentiteten klienten må vente. Ein eigen port er ikkje grunn til å slå av sertifikatkontroll eller byte protokollar. Skriv inn porten der den installerte klienten ventar han, og viss den klienten ikkje har eit slikt felt, er svaret ein annan godkjend klient og ikkje ein gjetta omveg.

Serveren har to portar, og begge må stemme

IKE startar på UDP 500, og NAT-gjennomgang flyttar vanlegvis IKE og innkapsla ESP til UDP 4500. Dette er separate innstillingar i strongSwan, så ein server som er flytt til éin eigen port må endre begge til same verdi:

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

Med éin port for begge rollene må demonen skilje IKE frå ESP-i-UDP på same socket, noko han gjer med den fire-byte-markøren som ikkje er ESP og som kjem før ei IKE-melding. Difor kan ein klient ikkje forhandle på den eigendefinerte porten og deretter halde fram stille på 4500, og difor skjuler setninga «berre byt porten» eit krav om innramming.

Ei vidaresending er ikkje ein lyttar

Vidaresending av 4443 til ein vanleg IKE-lyttar er feilmodusen som ser nesten vellukka ut. Den første utvekslinga kjem, serveren svarar, og deretter stoppar sambandet eller fornyar nøklar til ingenting, fordi svaret går ut frå ein annan port og den seinare innkapsla trafikken aldri samsvarar med tilstanden dei to endane laga. Ein regel som skriv om målporten utan å flytte lyttaren gir nøyaktig dette halvopne resultatet.

Vegen må óg tillate UDP frå ende til ende. At TCP 443 slepp gjennom eit hotell- eller operatørnett seier ingenting om IKEv2 på ein UDP-port, sjølv med same nummer. Der berre TCP 443 er tillate, gjer ein eigen UDP-port ikkje IKEv2 til HTTPS, og det rette svaret kan vere ein annan tilgangsveg i staden for nok eit porteksperiment.

Skil dei tre fasane når du testar

Tak opp på serveren medan klienten prøver éin gong. Ein førespurnad som aldri kjem er eit spørsmål om endepunkt eller brannmur; ein førespurnad som kjem utan svar er eit spørsmål om lyttar eller policy; eit svar som vert følgd av stille er spørsmålet om innramming eller identitet.

tcpdump -ni eth0 -vv udp port 4443

Les deretter meldinga frå klienten i staden for den snurrande indikatoren. Ein forslagsfeil betyr at algoritmane ikkje stemmer, ein autentiseringsfeil betyr at identitetar eller sertifikat ikkje stemmer, og gjentekne vidaresendingar utan svar betyr at ingenting svarar på den porten. Test éin fase om gongen og endre eitt felt mellom forsøka; strongSwan-dokumentasjonen om NAT-gjennomgang skildrar markøren og portåtferda som opptaket viser deg.