VPN-ul routerului funcționează, dar clienții LAN nu au internet

Starea spune că tunelul este activ, un browser de pe router încarcă pagini, iar fiecare dispozitiv din spatele lui tot expiră. Această combinație îngustează problema la un strat pe care majoritatea ghidurilor VPN nu îl menționează niciodată: routerul nu este singurul host ale cărui pachete trebuie să supraviețuiască tunelului. Traficul generat local și traficul redirecționat urmează căi diferite prin aceeași cutie. Testează de pe un client și diferența nu mai este teoretică.

Citește defectul de pe un host LAN

Începe cu dispozitivul care eșuează, pentru că o diagnoză rulată pe router răspunde la altă întrebare. Confirmă că gateway-ul implicit al clientului este acest router, notează adresa sursă și subrețeaua, apoi uită-te la ce iese din interfața de tunel a routerului.

Dacă adresa clientului este tradusă, partea îndepărtată vede adresa tunelului, iar de acolo totul pare sănătos în timp ce clientul tot eșuează. Dacă nu este tradusă, partea îndepărtată trebuie să cunoască o rută înapoi spre subrețeaua clientului, iar multe gateway-uri nu au o astfel de rută implicit. În orice caz, succesul routerului însuși este irelevant, pentru că pachetele lui au fost generate local și nu au trecut niciodată prin calea de redirecționare.

Traficul local și cel redirecționat sunt diferite

Linux și majoritatea firmware-urilor de router tratează pachetele originare din cutie altfel decât pachetele care o traversează. Lanțul output vede primul tip, lanțul forward îl vede pe al doilea, iar o politică adaptată traficului routerului însuși poate lăsa redirecționarea neatinsă.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Verifică dacă redirecționarea este activată deloc, apoi citește lanțul forward în loc de lanțul output. O regulă care permite conexiunea externă criptată nu este o regulă care permite redirecționarea pachetelor decriptate, iar confundarea celor două produce exact acest simptom. Tunelul activ dovedește doar prima.

Și calea de întoarcere trebuie să existe

Traducerea sursei decide dacă este nevoie de o cale de întoarcere. Cu masquerading pe interfața de tunel, răspunsurile se întorc la adresa tunelului, iar routerul le detraduce. Fără el, gateway-ul îndepărtat are nevoie de o rută explicită spre subrețeaua clientului, iar propria politică trebuie să permită acea direcție.

Notează care dintre cele două modele este folosit de implementare înainte de a schimba ceva, pentru că reparațiile indică direcții opuse. Adăugarea traducerii ascunde o rută de întoarcere lipsă și strică aplicațiile care au nevoie de adresa sursă originală. Adăugarea unei rute de întoarcere fără traducere eșuează în tăcere când firewall-ul îndepărtat aruncă sursa necunoscută. Alege unul, documentează-l și potrivește cealaltă parte.

DNS-ul clientului face parte din aceeași analiză. Resolverul routerului poate răspunde în timp ce un client îndreptat spre alt server nu primește nimic.

Verifică un flux permis și un flux refuzat

După corecție, testează o conexiune nouă de pe un client, nu o sesiune existentă a routerului. Apoi confirmă că un segment care nu ar trebui să folosească tunelul tot nu îl folosește.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Verifică adresa sursă observată la capătul îndepărtat, pentru că îți spune care model rulează de fapt. Verifică și căutarea numelui, nu doar adresa, pentru că comportamentul resolverului este o cale separată prin aceeași cutie.

Păstrează regulile limitate la rețelele de clienți care au nevoie de tunel și rezistă tentației de a dezactiva filtrul de redirecționare pentru ca un test să treacă. Acea schimbare repară testul și elimină granița pe care tunelul trebuia să o ofere. Scrie adresa sursă, decizia de traducere și ruta de întoarcere într-o singură notă, cu data.