VPN se conectează, dar dispozitivele din LAN nu sunt accesibile: ce trebuie verificat

Traficul intră în tunel, gateway-ul răspunde pe propria adresă și nimic din spatele lui nu răspunde. Acest tipar este obișnuit și nu este o contradicție: un răspuns de la gateway dovedește că tunelul s-a încheiat și nu dovedește nimic despre ce se întâmplă cu un pachet adresat dincolo de el. Cele două teste folosesc căi de cod diferite pe aceeași mașină.

De acum înainte testați ceva de cealaltă parte a gateway-ului. Adresa proprie a gateway-ului va continua să răspundă, oricât de stricată ar fi redirecționarea.

Gateway-ul răspunde din propriul său stiv

Un pachet adresat gateway-ului este livrat căii sale locale de intrare, unde nucleul decide dacă un socket în ascultare îl acceptă. Un pachet adresat unui host din spatele gateway-ului este livrat în schimb căii de redirecționare, unde se aplică un alt set de verificări. Redirecționarea poate fi dezactivată complet, sau nucleul o poate activa, iar apoi o regulă de filtru care nu menționează niciodată tunelul o poate respinge. Nimic din toate acestea nu afectează răspunsul propriu al gateway-ului, motiv pentru care simptomul induce în eroare atât de fiabil.

Paginile de administrare accesate prin tunel aparțin și ele primei categorii. Sunt dovezi despre tunel, nu despre rețeaua din spatele lui.

Urmați fluxul până la prima graniță care îl aruncă

Începeți de la client și confirmați ruta și adresa sursă pe care le va folosi fluxul. Apoi urmăriți gateway-ul pentru sosirea exact a acelui flux, și din nou pentru același flux care pleacă spre LAN. Dacă nu sosește niciodată, problema este de partea clientului sau în prefixele permise ale tunelului. Dacă sosește și nu pleacă niciodată, problema este în redirecționare sau într-un filtru al căii înainte, iar captura a spus deja care dintre ele.

Rularea aceluiași test de la gateway ascunde jumătatea interesantă, pentru că un pachet originat la gateway are altă sursă și altă cerință de întoarcere. Folosiți fluxul clientului, cu propria adresă sursă, la fiecare pas. O captură făcută pe interfața greșită produce prostii încrezătoare.

Rutele de întoarcere și firewall-urile hosturilor eșuează separat

După ce pachetul ajunge la host, încă trei lucruri trebuie să fie valabile. Serviciul trebuie să asculte pe adresa către care a fost trimis pachetul, firewall-ul hostului trebuie să îl accepte, și răspunsul trebuie să aibă o rută înapoi către grupul de clienți. Ultima eșuează des, pentru că ruta implicită a hostului indică un router care nu a auzit niciodată de intervalul tunelului. Rezultatul este o conexiune care se stabilește din perspectiva hostului și moare în tăcere în cealaltă direcție.

Testați intenționat calea de întoarcere trimițând de la client și urmărind întoarcerea. O captură unidirecțională rezolvă în secunde ceea ce o oră de speculații nu va rezolva.

Confirmați fiecare salt cu adresa sursă a clientului

Rulați verificările în ordine și păstrați fiecare ieșire, pentru că valoarea stă în comparație, nu într-o singură linie. Comenzile de mai jos fixează adresa sursă, arată ruta aleasă și capturează ambele părți ale redirecționării. Înlocuiți hostul LAN și interfața de tunel cu ale dumneavoastră.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Interogarea rutei arată dacă clientul ar trimite măcar acel pachet în tunel, iar ping-ul arată dacă s-a întors ceva de la host. Compararea celor două capturi separă sosirea de ieșire, deoarece un cadru pe interfața tunelului fără echivalent pe interfața LAN este o decizie de redirecționare, nu o defecțiune a serviciului. Când ambele capturi arată cererea și doar una arată răspunsul, ruta de întoarcere este suspectul rămas.

Notați ce adresă a răspuns și ce destinație redirecționată a eșuat. Acea frază face raportul acționabil în locul afirmației că serverul este inaccesibil.