De ce IKEv2 eșuează pe Android pe un port UDP nestandard

Gateway-ul răspunde la IKEv2 pe UDP 4443 dintr-un motiv, profilul are un câmp numit Server, tastați numele de host și portul, iar telefonul raportează că nu poate ajunge la server sau nu poate rezolva adresa. Nimic nu este blocat. Formularul nativ Android așteaptă un host, iar același lucru este valabil în Windows. Un port personalizat este o capacitate a clientului înainte de a fi o setare a serverului, și doar unii clienți vă lasă să o exprimați. Parcurgeți cele trei părți în ordine: ce poate spune clientul, pe ce ascultă serverul și dacă ambele capete încadrează pachetele la fel.

Ce a trimis de fapt telefonul

Un șir host:port într-un câmp destinat unui nume este rezolvat ca nume. Rezolvatorul nu returnează nimic pentru vpn.example.net:4443, iar eroarea pe care o vedeți este o eșuare de rezolvare a numelui sau de accesibilitate, nu un timeout pe un port. Această distincție contează, pentru că o nouă încercare cu un nume mai scurt sau cu altă rețea nu va repara niciodată un șir pe care formularul nu îl poate analiza.

Profilul nativ IKEv2 pe Android, ca și clientul VPN integrat din Windows, este fixat pe porturile IKE standard. Niciunul nu afișează un câmp de port, iar nicio editare a profilului nu adaugă unul. Dacă ascultătorul operatorului este într-adevăr pe 4443, clientul integrat este instrumentul greșit, nu unul configurat greșit.

Folosiți un client care afișează portul

Clientul strongSwan pentru Android documentează un port de server configurabil în setările avansate ale profilului, de aceea apare în aproape fiecare rețetă care funcționează pentru acest design. Acel suport aparține acelui client: o altă aplicație IKEv2, sau o variantă a furnizorului aceleiași aplicații, poate să nu afișeze același câmp chiar dacă daemonul strongSwan de dedesubt îl acceptă.

Cereți operatorului întregul set deodată: numele gateway-ului, portul UDP, metoda de autentificare și identitatea serverului pe care clientul trebuie să o aștepte. Un port personalizat nu este un motiv pentru a dezactiva verificarea certificatelor sau pentru a schimba protocoalele. Introduceți portul acolo unde clientul instalat îl așteaptă, iar dacă acel client nu are un astfel de câmp, răspunsul este un alt client aprobat, nu o soluție ghicită.

Serverul are două porturi, iar ambele trebuie să corespundă

IKE începe pe UDP 500, iar traversarea NAT mută de obicei IKE și ESP încapsulat pe UDP 4500. Acestea sunt setări separate în strongSwan, așa că un server mutat pe un singur port personalizat trebuie să le schimbe pe ambele la aceeași valoare:

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

Cu un singur port pentru ambele roluri, daemonul trebuie să distingă IKE de ESP-în-UDP pe același socket, ceea ce face prin marcatorul de patru octeți care nu este ESP și care precede un mesaj IKE. De aceea un client nu poate negocia pe portul personalizat și apoi continua în tăcere pe 4500, și de aceea sintagma „schimbați doar portul” ascunde o cerință de încadrare.

O redirecționare nu este un ascultător

Redirecționarea 4443 către un ascultător IKE obișnuit este modul de eșec care pare aproape reușit. Primul schimb ajunge, serverul răspunde, iar apoi conexiunea se blochează sau regenerează chei în nimic, pentru că răspunsul pleacă de pe alt port, iar traficul încapsulat ulterior nu corespunde niciodată stării create de cele două capete. O regulă care rescrie portul de destinație fără a muta ascultătorul produce exact acest rezultat pe jumătate deschis.

Calea trebuie să permită și UDP de la un capăt la altul. Faptul că TCP 443 trece printr-o rețea de hotel sau de operator nu spune nimic despre IKEv2 pe un port UDP, nici măcar cu același număr. Acolo unde este permis doar TCP 443, un port UDP personalizat nu transformă IKEv2 în HTTPS, iar răspunsul corect poate fi o altă cale de acces, nu încă un experiment cu portul.

Separați cele trei etape la testare

Capturați pe server în timp ce clientul încearcă o dată. O cerere care nu ajunge niciodată este o chestiune de punct final sau de firewall; o cerere care ajunge fără răspuns este o chestiune de ascultător sau de politică; un răspuns urmat de tăcere este chestiunea încadrării sau a identității.

tcpdump -ni eth0 -vv udp port 4443

Apoi citiți mesajul clientului, nu indicatorul lui rotativ. O eroare de propunere înseamnă că algoritmii nu corespund, o eșuare de autentificare înseamnă că identitățile sau certificatele nu corespund, iar retransmiterile repetate fără răspuns înseamnă că nimic nu răspunde pe acel port. Testați o etapă pe rând și schimbați un singur câmp între încercări; documentația strongSwan despre traversarea NAT descrie marcatorul și comportamentul portului pe care vi le arată captura.