Waarom Android se IKEv2 op ’n nie-standaard UDP-poort misluk

’n Inheemse IKEv2-vorm neem ’n adres, nie ’n poort nie. Bevestig dat die kliënt dit ondersteun, stel albei bedienerpoorte, kyk dan na die raamwerk en die logboeke.

Die poortweg antwoord IKEv2 op UDP 4443 om ’n rede, die profiel het ’n veld met die naam Server, jy tik die gasheernaam en die poort in, en die foon rapporteer dat dit die bediener nie kan bereik nie of die adres nie kan oplos nie. Niks word geblokkeer nie. Die inheemse Android-vorm verwag ’n gasheer, en dieselfde geld op Windows. ’n Pasgemaakte poort is ’n kliëntvermoë voordat dit ’n bedienerinstelling is, en net sommige kliënte laat jou dit uitdruk. Werk die drie dele in volgorde deur: wat die kliënt kan sê, waarop die bediener luister, en of albei kante die pakkette op dieselfde manier raam.

Wat die foon werklik gestuur het

’n Gasheer:poort-string in ’n veld wat vir ’n naam bedoel is, word as ’n naam opgelos. Die oplosser gee niks terug vir vpn.example.net:4443 nie, en die fout wat jy sien is ’n naamoplossings- of onbereikbaarheidsfout eerder as ’n tydverstreke op ’n poort. Daardie onderskeid maak saak, want om met ’n korter naam of ’n ander netwerk weer te probeer sal nooit ’n string regmaak wat die vorm nie kan ontleed nie.

Die inheemse IKEv2-profiel op Android, net soos die ingeboude Windows-VPN-kliënt, is vas aan die standaard IKE-poorte. Nie een van hulle het ’n poortveld nie, en geen hoeveelheid profielredigering voeg een by nie. As die operateur se luisteraar werklik op 4443 is, is die ingeboude kliënt die verkeerde instrument, nie ’n verkeerd opgestelde een nie.

Gebruik ’n kliënt wat die poort blootstel

Die strongSwan Android-kliënt dokumenteer ’n verstelbare bedienerpoort in sy gevorderde profielinstellings, daarom verskyn dit in byna elke werkende resep vir hierdie ontwerp. Daardie ondersteuning behoort aan daardie kliënt: ’n ander IKEv2-program, of ’n verskaffer-vurk van dieselfde program, het dalk nie dieselfde veld nie, selfs al ondersteun die onderliggende strongSwan-daemon dit.

Vra die operateur vir die hele stel gelyktydig: poortwegnaam, UDP-poort, verifikasiemetode en die bedieneridentiteit wat die kliënt moet verwag. ’n Pasgemaakte poort is nie ’n rede om sertifikaatkontrole af te skakel of om protokolle te verander nie. Voer die poort in waar die geïnstalleerde kliënt dit verwag, en as daardie kliënt nie so ’n veld het nie, is die antwoord ’n ander goedgekeurde kliënt eerder as ’n geraaide worde-om.

Die bediener het twee poorte, en albei moet ooreenstem

IKE begin op UDP 500, en NAT-deurgang skuif gewoonlik IKE en ingekapselde ESP na UDP 4500. Dit is afsonderlike instellings in strongSwan, so ’n bediener wat na ’n enkele pasgemaakte poort geskuif word, moet albei na dieselfde waarde verander:

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

Met een poort vir albei rolle moet die daemon IKE van ESP-in-UDP op dieselfde sok onderskei, wat dit doen deur die viergreep-merker wat aandui dat dit nie ESP is nie en wat ’n IKE-boodskap voorafgaan. Dit is waarom ’n kliënt nie op die pasgemaakte poort kan onderhandel en dan stilweg op 4500 kan voortgaan nie, en waarom die frase “verander net die poort” ’n raamwerkvereiste verberg.

’n Deurgee is nie ’n luisteraar nie

Die deurgee van 4443 na ’n gewone IKE-luisteraar is die foutmodus wat amper suksesvol lyk. Die eerste uitruiling kom aan, die bediener antwoord, en die verbinding stop dan of her-sleutel tot niks, want die antwoord verlaat ’n ander poort en die latere ingekapselde verkeer pas nooit by die toestand wat die twee kante geskep het nie. ’n Reël wat die bestemmingspoort herskryf sonder om die luisteraar te skuif, lewer presies hierdie half-oop resultaat.

Die pad moet ook UDP van punt tot punt toelaat. Om TCP 443 deur ’n hotel- of draadnetwerk te laat slaag, sê niks oor IKEv2 op ’n UDP-poort nie, selfs een met dieselfde nommer. Waar slegs TCP 443 toegelaat word, maak ’n pasgemaakte UDP-poort nie van IKEv2 ’n HTTPS nie, en die korrekte antwoord is dalk ’n ander toegangsroete eerder as nog ’n poorteëksperiment.

Skei die drie fases wanneer jy toets

Neem op die bediener vas terwyl die kliënt een keer probeer. ’n Versoek wat nooit aankom nie, is ’n eindpunt- of brandmuurvraag; ’n versoek wat aankom sonder antwoord is ’n luisteraar- of beleidsvraag; ’n antwoord wat deur stilte gevolg word, is die raamwerk- of identiteitsvraag.

tcpdump -ni eth0 -vv udp port 4443

Lees dan die kliënt se boodskap eerder as sy draaikring. ’n Voorstel-fout beteken die algoritmes stem nie ooreen nie, ’n verifikasiefout beteken identiteite of sertifikate stem nie ooreen nie, en herhaalde herversendings sonder reaksie beteken niks antwoord op daardie poort nie. Toets een fase op ’n slag en verander een veld tussen pogings; die strongSwan-dokumentasie oor NAT-deurgang beskryf die merker en poortgedrag wat die opname jou wys.

Verwante artikels