Tunel activ, fără internet: unde se oprește redirecționarea

Autentificarea și un tunel funcțional nu implică ieșire pe internet. Urmați o singură cerere prin adresarea sursei, prin redirecționare și prin calea de răspuns.

Clientul se conectează, tunelul duce pinguri către gateway și nimic dincolo de el nu răspunde. Acea stare este normală pentru un gateway care a fost menit doar să ofere acces la rețele protejate și este o defecțiune pentru unul anunțat ca ieșire de tunel complet. Înainte de a schimba reguli, confirmați ce serviciu a fost promis. Apoi urmați o singură cerere publică prin cele patru locuri în care se poate opri. O cerere și o captură de pachete lămuresc mai mult decât o pagină de presupuneri.

Confirmați dacă ieșirea pe internet a fost vreodată proiectul

Un profil de tunel divizat direcționează doar subrețelele protejate în VPN, așa că navigarea publică continuă pe legătura locală și nu atinge niciodată gateway-ul. Un profil de tunel complet instalează o rută implicită în tunel, ceea ce face gateway-ul responsabil pentru întreaga cale. Ambele sunt proiecte legitime, iar confundarea lor produce un raport de defecțiune acolo unde nu există niciuna. Citiți rutele anunțate de client înainte de a testa orice altceva, pentru că tabelul de rute răspunde la întrebarea pe care tichetul o pune de obicei greșit.

Ce instalează clientul nu este întotdeauna ce intenționează profilul. O rută împinsă poate fi anulată de o rută locală cu metrică mai mică, iar un client care își păstrează ruta LAN în timp ce adaugă o rută implicită se comportă ca un tunel divizat pentru acea subrețea.

Urmați o singură cerere publică

Alegeți o singură destinație și urmăriți-o de la client spre exterior. Pe client, verificați dacă pachetul selectează într-adevăr tunelul și ce adresă locală folosește ca sursă. Verificați apoi gateway-ul: pachetul ajunge și părăsește interfața publică. Fiecare dintre aceste răspunsuri elimină o categorie întreagă de cauze.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Dacă gateway-ul nu vede niciodată pachetul, ruta clientului sau selecția tunelului este greșită. Dacă ajunge și nu pleacă, problema este la gateway, iar cele trei verificări rămase se aplică.

Verificați redirecționarea, ruta și traducerea

Ghidul de redirecționare livrat cu strongSwan se aplică unui gateway de orice tip de tunel: kernel-ului trebuie să i se permită să mute pachete între interfețe, iar o rută utilizabilă trebuie să indice spre internet. Politica firewall-ului trebuie să permită apoi traficul, iar adresa sursă trebuie să fie una la care partea publică poate răspunde. O adresă privată de client redirecționată neschimbată spre internet nu primește niciodată răspuns.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Traducerea sursei este piesa lipsă obișnuită. Cu ea, gateway-ul rescrie sursa clientului la adresa sa publică și urmărește fluxul; fără ea, răspunsul nu are unde să meargă. Platformele cloud adaugă o a doua limită, unde tabelul de rute sau grupul de securitate al instanței poate elimina trafic pe care firewall-ul guestului îl permite. Acea limită este ușor de ratat pentru că sistemul guest pare configurat corect din interior.

Filtrarea pe calea inversă într-o configurație asimetrică poate de asemenea să elimine pachete valide. Citiți contorul acelei reguli în loc să presupuneți că este în regulă, pentru că o setare strictă pe interfața publică respinge traficul care sosește pe o cale diferită de cea prezisă de tabelul de rute.

Calea de răspuns și resolverul sunt două răspunsuri diferite

Urmăriți și răspunsul, nu doar cererea. Dacă cererea pleacă tradusă și răspunsul revine în fluxul tradus, redirecționarea funcționează chiar dacă aplicația încă eșuează, iar următoarea investigație aparține aplicației sau DNS-ului.

Un site care returnează o eroare HTTP este dovada că redirecționarea pe internet funcționează. Un nume care nu se rezolvă în timp ce accesul pe adresă funcționează este o problemă de resolver, nu de NAT.

După o corecție îngustă, retestați clientul plus orice resursă privată restricționată intenționat. Acordarea accesului la internet nu trebuie să lărgească în tăcere accesul la fiecare rețea conectată la gateway.

Articole similare