Tunelul complet în strongSwan necesită 0.0.0.0/0 pe ambele părți

Un tunel complet necesită 0.0.0.0/0 ca remote_ts al clientului și ca local_ts al gateway-ului, plus redirecționare, NAT și o rută de întoarcere. Verificați toate patru.

O conexiune strongSwan care funcționează pentru o singură subrețea privată nu va transporta trafic de internet doar pentru că cineva a editat o linie. Un tunel complet este un acord între două părți despre ce adrese protejează child SA, iar fiecare parte o numește pe cealaltă raportat la sine. Faci o parte corect și cealaltă greșit, iar child SA fie nu urcă, fie urcă mai îngust decât s-a intenționat. Cele cinci verificări de mai jos urmăresc acel acord de la client, prin gateway, până la internet.

Verificați mai întâi selectorul clientului

Clientul descrie ce vrea să protejeze pe partea îndepărtată ca remote_ts, iar tot ce trimite provine din adresa proprie alocată. Pentru traficul de internet acea valoare trebuie să acopere destinațiile la care utilizatorul va ajunge efectiv, ceea ce în practică înseamnă tot spațiul IPv4. Un client care încă listează o singură subrețea cere un tunel divizat, oricum ar fi numit profilul în interfață. Partea sursă este de obicei dynamic deoarece adresa este alocată la conectare. O sursă fixă scrisă acolo se rupe imediat ce se schimbă grupul de adrese.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Fragmentul nu este un fișier de conexiune complet, iar acesta presupune că autentificarea, identitățile și grupul de adrese virtuale sunt deja configurate. Selectorul sursă al clientului și adresa alocată de server trebuie încă să coincidă, altfel child SA urcă cu o acoperire pe care niciuna dintre părți nu o aștepta. Încărcați-l cu swanctl --load-all și citiți ieșirea înainte de a presupune succes. Un fișier care se parsează poate fi totuși respins din cauza unui selector care nu se suprapune cu propunerea celeilalte părți.

Verificați selectorul gateway-ului pe partea lui

Gateway-ul citește același concept din direcția opusă. Destinațiile de internet sunt locale pentru gateway, așa că local_ts al acestuia este cel larg și remote_ts descrie grupul de clienți. Această inversare este cea mai frecventă greșeală într-o configurație de tunel complet și trece de revizuire pentru că ambele linii par plauzibile separat.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copierea fragmentului clientului în fișierul gateway-ului produce o pereche de selectori care nu descrie nimic util, pentru că ambele părți ar revendica același rol. Ghidul de redirecționare al strongSwan documentează explicit împerecherea clientului și a gateway-ului, și merită citit lângă fișierul de conexiune, nu după eșec. Fișierul gateway-ului are nevoie și de definiția grupului la care face referire remote_ts. Un selector care numește un grup inexistent se încarcă fără reclamații și eșuează la conectare.

Vechiul ipsec.conf folosește rolurile stânga și dreapta cu chei diferite, iar o linie rightsubnet nu este un înlocuitor direct pentru valoarea swanctl. Țineți cele două sintaxe în fișiere separate în loc să lipiți una în cealaltă. Amestecarea lor într-un singur director este modul în care o conexiune funcțională revine în tăcere după o repornire.

Verificați child SA negociată, nu fișierul

O configurație salvată dovedește intenția și nimic mai mult. Cealaltă parte poate restrânge ce s-a cerut, iar o child SA existentă nu este înlocuită doar pentru că fișierul de sub ea s-a schimbat. Confirmați ce este efectiv instalat înainte de a schimba orice altceva.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Prima comandă arată ce a încărcat demonul, a doua arată child SA stabilite, iar a treia politicile pe care le va aplica nucleul. Dacă fișierul spune 0.0.0.0/0 și listarea arată o singură subrețea, negocierea a restrâns domeniul și recitirea fișierului nu va explica asta. Terminați child, reporniți-o și comparați din nou toate cele trei ieșiri. O child care revine cu același domeniu îngust este restrânsă de partea îndepărtată și nu de fișierul local, iar aceasta este o conversație cu celălalt administrator în loc de o modificare locală.

Citiți ambele direcții în listarea politicilor, pentru că un tunel care instalează o direcție și nu pe cealaltă este o problemă de rutare în costum de configurație. Politicile dus și întors trebuie să numească aceeași pereche de selectori în imagine oglindă, iar o oglindă lipsă este un defect al demonului sau al propunerii, nu al textului selectorului.

Verificați redirecționarea și ruta de întoarcere

Un selector admite traficul către gateway, dar nu face gateway-ul să ruteze acel trafic mai departe. Redirecționarea trebuie activată, firewall-ul trebuie să permită fluxul, iar răspunsul trebuie să găsească drumul înapoi la grupul de clienți. Sunt trei cerințe separate, iar fiecare eșuează cu un simptom diferit. O regulă de redirecționare lipsă se comportă ca o gaură neagră, în timp ce o rută de întoarcere lipsă se comportă ca un tunel cu sens unic.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Adresele private ale clienților au de obicei nevoie de o traducere de sursă deliberată înainte de a putea părăsi o interfață publică, în timp ce o alocare rutată explicit necesită alt tratament. Dacă NAT este implicat, păstrați excepțiile acceptate de implementare, astfel încât traficul pe care o politică de securitate ar trebui să îl inspecteze să nu fie tradus pe lângă ea. O regulă masquerade largă copiată de la alt gateway schimbă mult mai multe fluxuri decât a intenționat autorul ei. Scrieți regula doar pentru grupul de clienți și lăsați un comentariu care explică de ce există.

Pe client, confirmați rutele instalate de backend, nu rutele pe care le-ați presupus. Un manager cu instalarea rutelor dezactivată are nevoie de un design de rutare întreținut manual, iar acel design trebuie actualizat de fiecare dată când tunelul se schimbă. Verificați tabelul de rutare după reconectare, nu doar după o pornire curată.

Verificați ce nu acoperă încă tunelul

Perechea de selectori acoperă IPv4 și nimic altceva. IPv6, DNS și orice politică la nivel de aplicație sunt decizii separate pe care un selector IPv4 larg le ignoră în tăcere. Un tunel care transportă fiecare pachet IPv4 poate încă scurge fiecare căutare de nume.

Declarați explicit calea DNS prevăzută, pentru că un tunel complet care încă rezolvă nume prin resolverul local scurge interogări în afara tunelului și strică numele private. Dacă clientului i se alocă o adresă IPv6, acea familie de adrese necesită același tratament, altfel gazda va prefera o cale pe care tunelul nu o protejează. Testați cu un nume la care doar partea privată poate răspunde și tratați un răspuns public ca o scurgere.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirmați lanțul cu cele două comenzi plus selectorii negociați din listarea de mai sus. Dacă traceroute arată routerul local ca primul salt, traficul nu folosește tunelul, orice ar afirma selectorii. Accesul la internet este complet doar când traficul ales este admis, redirecționat și returnat prin gateway-ul proiectat. Găsirea 0.0.0.0/0 într-un profil este începutul acelui lanț, nu dovada lui.

Articole similare