strongSwan ESP-in-UDP: când nu există NAT de detectat

Detectarea NAT găsește traducerea adreselor, nu politica firewall-ului. O conexiune de site fără NAT poate totuși necesita o alegere explicită ESP-in-UDP.

Detectarea NAT răspunde la o întrebare: s-au schimbat adresele sau porturile pe parcurs? Nu răspunde dacă un firewall permite protocolul IP 50. Gateway-urile de site fără nicio traducere pot sta în continuare în spatele unei politici care aruncă native ESP, iar acea cerință trebuie configurată, nu descoperită. Mecanismul este ESP-in-UDP și este o decizie, nu o soluție de rezervă care apare de la sine.

Detectarea este aritmetică pe adrese, nu o sondă a firewall-ului

IKEv2 transportă încărcături utile de detectare NAT cu hash-uri ale adreselor și porturilor sursă și destinație. Fiecare parte compară ce a primit cu ce vede local, iar o nepotrivire îi spune că ceva a tradus pachetul. Nimic din acel schimb nu testează dacă un router din mijloc transmite protocolul 50.

Merită spus direct consecința practică. Un tunel care funcționa cu native ESP nu va descoperi singur un firewall nou restrictiv, iar următoarea încercare eșuează în etapa de date în timp ce IKE continuă să reușească. Veți vedea asocieri de securitate IKE stabilite și niciun trafic protejat, ceea ce arată ca o defecțiune de rutare până când capturați pe fir.

Encapsularea este așadar o proprietate a conexiunii pe care o configurați, nu un rezultat pe care părțile îl negociază din comportamentul rețelei.

Cum schimbă encap schimbul

Într-o implementare modernă strongSwan administrată prin swanctl.conf, setarea encap = yes pe conexiune influențează schimbul de detectare NAT astfel încât ambele părți să folosească encapsulare UDP pentru ESP. Pachetele protejate călătoresc apoi în UDP, de obicei pe portul 4500, iar ambele capete trebuie să fie de acord cu această aranjare.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Acest fragment aparține unei definiții reale de conexiune și nu este un profil complet de site. Păstrați adresele partenerilor, autentificarea și selectorii de trafic child pe care îi rulați deja; singura cheie adăugată schimbă modul în care sunt împachetate datele protejate, nu ce protejează.

Ghidul strongSwan despre NAT-traversal descrie acest comportament, inclusiv interacțiunea cu portul plutitor atunci când se folosește MOBIKE.

Folosiți setarea care aparține backend-ului dvs

strongSwan are două backend-uri de configurare, iar cheia diferă între ele. O swanctl.conf conexiune ia encap, în timp ce o ipsec.conf conexiune veche ia forceencaps. Introducerea cuvântului-cheie al unui backend în celălalt produce o configurație care se încarcă fără reclamații și nu schimbă nimic, ceea ce este mai rău decât o eroare.

Verificați ce daemon rulează de fapt înainte de a edita ceva. În multe distribuții există ambele fișiere pentru că unul este o rămășiță a unei migrări anterioare, iar cel activ este cel pe care îl pornește unitatea de serviciu. Citiți acea unitate în loc să ghiciți din marcajele de timp ale fișierelor. O verificare de cinci secunde aici evită ore de testare a unei setări pe care nimic nu a încărcat-o.

Aplicați schimbarea prin proprietarul conexiunii și restabiliți asocierea într-o fereastră controlată. Un child deja instalat își păstrează encapsularea actuală până când este înlocuit, deci doar editarea fișierului nu dovedește că noua aranjare este în uz.

Verificați datele împachetate, nu doar portul

Capturați pe gateway în timp ce curge trafic protejat, apoi comparați cu propria vedere a strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP apare ca protocol IP 50 și nu seamănă deloc cu UDP. ESP împachetat apare ca datagrame UDP pe 4500 a căror încărcătură utilă nu este IKE. Traficul IKE pe același port nu este dovadă de encapsulare, pentru că MOBIKE poate muta IKE acolo în timp ce calea de date rămâne native, așa că citiți încărcătura utilă, nu numărul de port.

Aveți în vedere și MTU-ul căii. Învelișul adaugă suprasarcină, iar o cale care transporta native ESP poate necesita ajustări când pachetele cresc. Gestionarea ICMP necesară ar trebui să facă deja parte din proiectare; encapsularea nu elimină această dependență.

Acceptați schimbarea când traficul nou al aplicațiilor din tunel este vizibil în captură ca ESP împachetat la ambele capete și când serviciul intern și ruta sa de întoarcere încă funcționează. Orice mai puțin este o configurație care pare corectă într-un fișier.

Articole similare