VPN spune conectat, dar nimic nu este rutat: două locuri de verificat

Un tunel poate raporta conectat în timp ce nimic nu ajunge la el, iar cele două fapte stau în locuri diferite. Unul este tabelul de rute, care poate încă trimite pachete către un dispozitiv pe care nu îl deține nimeni. Celălalt este rezolvatorul, care poate încă lista un server pe o legătură care a dispărut. Schimbarea de rețea nu a deteriorat profilul, a orfanizat starea care aparținea conexiunii anterioare, iar repararea depinde de care dintre cele două te uiți de fapt.

Mai întâi întreabă nucleul ce dispozitiv ar folosi

O listare de rute arată ce există; o căutare de rută arată ce s-ar întâmpla. Întreabă despre o adresă publică și citește numele dispozitivului în răspuns, pentru că acel singur câmp decide dacă pachetul ajunge undeva util. Când răspunsul numește un dispozitiv de tunel, nucleul îi predă pachetele chiar dacă în spatele acelei interfețe nu mai rulează niciun proces client. Când răspunsul numește adaptorul fizic în timp ce clientul susține că este conectat, tunelul este ridicat și pur și simplu nu este calea aleasă.

Al doilea caz este cel obișnuit după ce un cablu înlocuiește rețeaua fără fir, și se prezintă ca un VPN stricat.

ip route show default
ip route get 203.0.113.9

Citește apoi intrările implicite, fiindcă o rută adăugată de conexiunea de bază anterioară poate supraviețui unei schimbări de legătură și poate sta în fața celei noi. O rută implicită printr-un dispozitiv care este picat este mai rea decât nicio rută implicită, pentru că nucleul o preferă în continuare. Observă metrica de lângă fiecare intrare, fiindcă acea ordine explică preferința mai repede decât numele interfețelor.

Apoi citește rezolvatorul pe legătură, nu pe fișier

Rezolvarea numelor poartă propriul stat și propria învechire. Un rezolvator care listează servere DNS pe legătură păstrează serverele unei legături de tunel care este picată dar încă înregistrată, iar fiecare interogare așteaptă atunci un server care nu va răspunde. Simptomul este o rețea care pare moartă în timp ce tabelul de rute arată perfect.

Inspectează starea pe legătură în locul fișierului, fiindcă pe multe distribuții acel fișier este o legătură simbolică în rezolvator și editarea lui nu face nimic sau este suprascrisă repede. Uită-te la ce legătură deține ce servere și ce domeniu de căutare, apoi întreabă dacă legătura de tunel ar mai trebui să fie înregistrată. Dacă nu ar trebui, dezactivează conexiunea care o deține în loc să editezi manual stare generată. Un nume care se rezolvă în timp ce căutarea de rută trimite pachetele altundeva este o a treia defecțiune, separată.

resolvectl status
resolvectl query app.internal.example

Dacă adresele se rezolvă și conexiunile eșuează, rezolvatorul este în regulă și ruta nu. Dacă adresele nu se rezolvă deloc, acesta este locul potrivit de unde să începi.

Cum supraviețuiește o rută învechită schimbării

Clientul nu deține rețeaua de unul singur. Pe un host cu NetworkManager un profil VPN este activat peste o conexiune de bază, iar setările conexiunii permit acelei baze să numească VPN-ul care ar trebui să o urmeze. Când baza se schimbă pentru că alt profil devine preferat, tunelul urmează pe noua bază sau rămâne fără niciuna.

Un profil VPN nu se ridică singur, așa că împerecherea contează mult mai mult decât preferința de conectare automată a profilului însuși.

Citește lista activă și notează care bază este ridicată înainte de a atinge tunelul. Dacă baza apare și tunelul nu, ruta lipsește în loc să fie învechită, iar reparația este activarea. Dacă activarea tunelului se plânge că nu există conexiune sursă, baza cu care era împerecheat a dispărut, așa că ridic-o mai întâi sau repară împerecherea în loc să reîncerci tunelul. Reîncercarea unui profil al cărui părinte lipsește produce aceeași eroare de fiecare dată, ceea ce este un semnal util și nu o pacoste.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Deosebește starea învechită de un părinte lipsă

Trei stări explică aproape fiecare raport, iar fiecare are nevoie de o reparație diferită. O rută implicită printr-un dispozitiv care încă există dar nu mai poartă tunelul este stare învechită, curățată fie ștergând intrarea, fie repornind profilul responsabil. Un dispozitiv de tunel al cărui proces client a dispărut este o defecțiune de curățare, așa că atenția merită calea de deconectare și nu tabelul de rute. Niciun dispozitiv de tunel înseamnă că lipsește părintele sau împerecherea și că tabelul de rute nu a fost niciodată implicat.

O repornire ascunde care dintre cele trei a fost, și exact de aceea pare o reparație.

După reparație, întreabă nucleul pentru o adresă publică și una internă, apoi interoghează un nume intern. Când adresa funcționează și numele nu, ai găsit o problemă de scop de domeniu în rezolvator și nu una de rutare. Notează ce stare ai găsit, fiindcă următoarea schimbare de rețea o va reproduce pe cea pe care ai lăsat-o în pace.