Pse IKEv2 në Android dështon në një port UDP jo standard

Gateway-i përgjigjet IKEv2 në UDP 4443 për një arsye, profili ka një fushë të quajtur Server, ju shkruani emrin e hostit dhe portën, dhe telefoni raporton se nuk arrin dot serverin ose nuk e zgjidh dot adresën. Asgjë nuk po bllokohet. Formulari vendas i Android pret një host, dhe e njëjta gjë vlen në Windows. Një port i personalizuar është aftësi e klientit përpara se të jetë cilësim i serverit, dhe vetëm disa klientë ju lejojnë ta shprehni. Kaloni nëpër tre pjesët me radhë: çfarë mund të thotë klienti, çfarë dëgjon serveri dhe nëse të dy skajet e kornizojnë paketën në të njëjtën mënyrë.

Çfarë dërgoi telefoni në të vërtetë

Një varg host:port në një fushë të destinuar për një emër zgjidhet si emër. Zgjidhësi nuk kthen asgjë për vpn.example.net:4443, dhe gabimi që shihni është dështim i zgjidhjes së emrit ose i paarritshmërisë, jo skadim kohe në një port. Ky dallim ka rëndësi, sepse riprovimi me një emër më të shkurtër ose një rrjet tjetër nuk do të rregullojë kurrë një varg që formulari nuk mund ta analizojë.

Profili vendas i IKEv2 në Android, si klienti i integruar i VPN-së në Windows, është i fiksuar në portat standarde të IKE. Asnjëri nuk shfaq një fushë porte, dhe asnjë redaktim i profilit nuk shton një. Nëse dëgjuesi i operatorit është me të vërtetë në 4443, klienti i integruar është mjeti i gabuar, jo një mjet i konfiguruar gabimisht.

Përdorni një klient që shfaq portën

Klienti strongSwan për Android dokumenton një port serveri të konfigurueshëm në cilësimet e avancuara të profilit, prandaj shfaqet pothuajse në çdo recetë që funksionon për këtë dizajn. Ai mbështetje i përket atij klienti: një aplikacion tjetër IKEv2, ose një fork i furnizuesit të të njëjtit aplikacion, mund të mos shfaqë të njëjtën fushë edhe pse daemoni strongSwan nën të e mbështet.

Kërkojini operatorit të gjithë grupin menjëherë: emrin e gateway-it, portën UDP, metodën e vërtetimit dhe identitetin e serverit që klienti duhet të presë. Një port i personalizuar nuk është arsye për të çaktivizuar kontrollin e certifikatave ose për të ndryshuar protokollet. Futni portën atje ku klienti i instaluar e pret, dhe nëse ai klient nuk ka një fushë të tillë, përgjigja është një klient tjetër i miratuar, jo një zgjidhje e hamendësuar.

Serveri ka dy porta, dhe të dyja duhet të përputhen

IKE fillon në UDP 500, dhe kalimi NAT zakonisht i zhvendos IKE dhe ESP-në e inkapsuluar në UDP 4500. Këto janë cilësime të veçanta në strongSwan, prandaj një server i zhvendosur në një port të vetëm të personalizuar duhet t'i ndryshojë të dyja në të njëjtën vlerë:

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

Kur një port shërben të dy rolet, daemoni duhet të dallojë IKE nga ESP-brenda-UDP në të njëjtin socket, gjë që e bën me shënuesin katër-bajtësh që nuk është ESP dhe që i paraprin një mesazhi IKE. Prandaj një klient nuk mund të negociojë në portën e personalizuar dhe më pas të vazhdojë në heshtje në 4500, dhe prandaj fraza “thjesht ndrysho portën” fsheh një kërkesë për kornizim.

Një përcjellje nuk është dëgjues

Përcjellja e 4443 në një dëgjues të zakonshëm IKE është mënyra e dështimit që duket pothuajse e suksesshme. Shkëmbimi i parë arrin, serveri përgjigjet, dhe pastaj lidhja ngec ose rigjeneron çelësat në asgjë, sepse përgjigja del nga një port tjetër dhe trafiku i inkapsuluar i mëpasshëm nuk përputhet kurrë me gjendjen që krijuan të dy skajet. Një rregull që rishkruan portën e destinacionit pa lëvizur dëgjuesin jep pikërisht këtë rezultat gjysmë të hapur.

Rruga duhet të lejojë gjithashtu UDP nga skaji në skaj. Kalimi i TCP 443 përmes një rrjeti hoteli ose operatori nuk thotë asgjë për IKEv2 në një port UDP, edhe me të njëjtin numër. Aty ku lejohet vetëm TCP 443, një port UDP i personalizuar nuk e kthen IKEv2 në HTTPS, dhe përgjigja e saktë mund të jetë një rrugë tjetër aksesi, jo një eksperiment tjetër me portën.

Ndani tre fazat gjatë testimit

Regjistroni në server ndërsa klienti provon një herë. Një kërkesë që nuk arrin kurrë është çështje pike fundore ose muri zjarri; një kërkesë që arrin pa përgjigje është çështje dëgjuesi ose politike; një përgjigje e ndjekur nga heshtja është çështja e kornizimit ose e identitetit.

tcpdump -ni eth0 -vv udp port 4443

Më pas lexoni mesazhin e klientit dhe jo treguesin e tij rrotullues. Një gabim propozimi do të thotë që algoritmet nuk përputhen, një dështim vërtetimi do të thotë që identitetet ose certifikatat nuk përputhen, dhe ritransmetimet e përsëritura pa përgjigje do të thotë që asgjë nuk përgjigjet në atë port. Testoni një fazë në një herë dhe ndryshoni një fushë midis provave; dokumentacioni i strongSwan për kalimin NAT përshkruan shënuesin dhe sjelljen e portës që regjistrimi po ju tregon.