IKEv2 folosește UDP 500 și 4500: care dintre ele transportă datele?

Deschiderea UDP 500 în firewall lasă tunelul să negocieze, iar apoi conexiunea nu mai trece trafic. Lista de porturi era incompletă, nu greșită. IKEv2 începe pe un socket și, în multe implementări reale, continuă pe altul, în timp ce payload-ul poate să nu fie deloc un port. Citirea etapelor în ordine explică ce regulă lipsește.

Două porturi, două roluri

IKEv2 începe cu un schimb de chei pe UDP 500, unde părțile se autentifică și stabilesc o asociere de securitate pentru tunel. Calea de date care urmează este o chestiune separată: poate fi ESP nativ, adică un număr de protocol IP și nu un port, sau trafic încapsulat în UDP pe 4500. Separarea acestora într-o revizuire a firewall-ului este diferența dintre un tunel care negociază și un tunel care funcționează. Un socket duce controlul, celălalt payload-ul.

De aceea o regulă care permite doar 500 produce cel mai confuz simptom din întreaga familie de protocoale: negocierea reușește și nimic util nu urmează. Starea arată un peer, jurnalul arată o IKE SA stabilită, iar aplicația tot expiră. Permisiunea lipsă aparține unui alt flux decât cel care tocmai a reușit.

De ce există 4500

Multe dispozitive NAT nu pot transmite alt protocol decât TCP sau UDP, iar unele rescriu adresele în moduri care strică verificarea de integritate a ESP. Încapsularea ESP în UDP rezolvă ambele probleme, cu prețul unui antet suplimentar și al unui al doilea port care trebuie permis. Tocmai această încapsulare este motivul pentru care există al doilea port.

După ce NAT este detectat, IKE însuși trece pe 4500 pentru ca tot traficul să împartă o singură cale prin traducător. Un marcaj de patru octeți care nu este ESP distinge mesajele de control de date pe acel socket. Trecerea este o decizie a protocolului, nu o preferință a administratorului.

Unde se schimbă portul sursă

Un traducător poate rescrie portul sursă al clientului, astfel încât tuplul văzut pe server nu corespunde tuplului de pe client. Uitați-vă la ambele capete ale fiecărui salt NAT înainte de a concluziona că o regulă este ignorată. Diagnosticarea doar pe client poate produce o regulă care pare corectă și tot eșuează.

Implementările compatibile cu MOBIKE pot trece și ele pe 4500 fără NAT detectat, iar unele implementări forțează deliberat această cale. A vedea 4500 este așadar dovada unei decizii, nu dovada unui router de acasă.

Verificați ambele fluxuri la fiecare graniță

Parcurgeți cele trei granițe: rețeaua clientului, orice firewall intermediar și serverul. Fiecare are nevoie de fluxurile documentate de implementare, nu de fluxurile dintr-un articol despre alt caz.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Linia ESP dintr-o listă de firewall este o potrivire de protocol, așa că o regulă de port nu o acoperă niciodată. Dacă operatorul folosește un port personalizat, urmați configurația documentată la ambele capete, pentru că un client nu poate crea un ascultător pe server alegând un număr familiar.

Notați unde s-a oprit negocierea și dacă a fost instalată o asociere de securitate copil, deoarece acea pereche separă o cale blocată de o eroare de autentificare sau de politică. Apoi repetați testul cu verificarea serverului activată, deoarece accesibilitatea nu este autentificare. Acel ultim pas separă un port permis de un peer de încredere.