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

Et innebygd IKEv2-skjema tar en adresse, ikke en port. Bekreft at klienten støtter det, sett begge serverportene, og se deretter på innrammingen og loggene.

Gatewayen svarer på IKEv2 på UDP 4443 av en grunn, profilen har et felt kalt Server, du skriver inn vertsnavnet og porten, og telefonen rapporterer at den ikke når serveren eller ikke kan slå opp adressen. Ingenting blir blokkert. Det innebygde Android-skjemaet forventer en vert, og det samme gjelder i Windows. En egendefinert port er en klientegenskap før den er en serverinnstilling, og bare noen klienter lar deg uttrykke den. Gå gjennom de tre delene i rekkefølge: hva klienten kan si, hva serveren lytter på, og om begge ender rammer inn pakkene på samme måte.

Hva telefonen faktisk sendte

En vert:port-streng i et felt beregnet på et navn løses opp som et navn. Oppløseren returnerer ingenting for vpn.example.net:4443, og feilen du ser er en navneoppløsnings- eller utilgjengelighetsfeil, ikke en tidsavbrudd på en port. Den forskjellen betyr noe, fordi et nytt forsøk med et kortere navn eller et annet nettverk aldri vil reparere en streng som skjemaet ikke kan tolke.

Den innebygde IKEv2-profilen på Android er, som den innebygde Windows VPN-klienten, låst til de standard IKE-portene. Ingen av dem viser et portfelt, og ingen profilredigering legger til ett. Hvis operatørens lytter faktisk er på 4443, er den innebygde klienten feil verktøy, ikke et feilkonfigurert et.

Bruk en klient som viser porten

strongSwan-klienten for Android dokumenterer en konfigurerbar serverport i de avanserte profilinnstillingene, og derfor dukker den opp i nesten hver oppskrift som fungerer for dette designet. Den støtten tilhører den klienten: en annen IKEv2-app, eller en leverandørfork av samme app, viser kanskje ikke det samme feltet selv om den underliggende strongSwan-demonen støtter det.

Be operatøren om hele settet på én gang: gatewaynavn, UDP-port, autentiseringsmetode og serveridentiteten klienten må forvente. En egendefinert port er ikke grunn til å slå av sertifikatkontroll eller bytte protokoller. Skriv inn porten der den installerte klienten forventer den, og hvis den klienten ikke har et slikt felt, er svaret en annen godkjent klient og ikke en gjettet omvei.

Serveren har to porter, og begge må stemme

IKE starter på UDP 500, og NAT-gjennomgang flytter vanligvis IKE og innkapslet ESP til UDP 4500. Dette er separate innstillinger i strongSwan, så en server som er flyttet til én egendefinert port må endre begge til samme verdi:

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

Med én port for begge rollene må demonen skille IKE fra ESP-i-UDP på samme socket, noe den gjør med den fire-byte-markøren som ikke er ESP og som kommer før en IKE-melding. Derfor kan en klient ikke forhandle på den egendefinerte porten og deretter fortsette stille på 4500, og derfor skjuler setningen «bare bytt porten» et krav om innramming.

En videresending er ikke en lytter

Videresending av 4443 til en vanlig IKE-lytter er feilmodusen som ser nesten vellykket ut. Den første utvekslingen ankommer, serveren svarer, og deretter stopper forbindelsen eller fornyer nøkler til ingenting, fordi svaret går ut fra en annen port og den senere innkapslede trafikken aldri samsvarer med tilstanden de to endene laget. En regel som skriver om målporten uten å flytte lytteren gir nøyaktig dette halvåpne resultatet.

Veien må også tillate UDP fra ende til ende. At TCP 443 slipper gjennom et hotell- eller operatørnett sier ingenting om IKEv2 på en UDP-port, selv med samme nummer. Der bare TCP 443 er tillatt, gjør en egendefinert UDP-port ikke IKEv2 til HTTPS, og det riktige svaret kan være en annen tilgangsvei i stedet for nok et porteksperiment.

Skille de tre fasene når du tester

Ta opp på serveren mens klienten prøver én gang. En forespørsel som aldri kommer er et spørsmål om endepunkt eller brannmur; en forespørsel som kommer uten svar er et spørsmål om lytter eller policy; et svar som etterfølges av stillhet er spørsmålet om innramming eller identitet.

tcpdump -ni eth0 -vv udp port 4443

Les deretter meldingen fra klienten i stedet for den snurrende indikatoren. En forslagsfeil betyr at algoritmene ikke stemmer, en autentiseringsfeil betyr at identiteter eller sertifikater ikke stemmer, og gjentatte videresendinger uten svar betyr at ingenting svarer på den porten. Test én fase om gangen og endre ett felt mellom forsøkene; strongSwan-dokumentasjonen om NAT-gjennomgang beskriver markøren og portoppførselen som opptaket viser deg.

Relaterte artikler