Rută VPN lipsă în NetworkManager: politică de profil sau un script?
Tunelul se conectează și un prefix nu apare niciodată. Decideți între politica profilului, datele pluginului și un al doilea proprietar al rutei înainte de a adăuga un script auxiliar.
Vă conectați, interfața tunelului apare, iar un prefix de care aveți nevoie pur și simplu nu este în tabel. Pasul următor este de obicei căutarea unui script care îl adaugă. Căutarea ajunge la răspunsuri care lipesc un ajutor OpenVPN într-un profil, iar jumătate dintre acele răspunsuri înrăutățesc situația în loc să o îmbunătățească, pentru că o rută lipsă are trei proprietari posibili și doar unul dintre ei este un script lipsă.
Decideți ce proprietar este responsabil înainte de a scrie ceva.
Trei proprietari, un prefix lipsă
Prefixul poate lipsi pentru că nimeni nu l-a furnizat, pentru că profilul l-a refuzat sau pentru că a fost instalat într-un loc în care nu vă uitați. Sunt defecte diferite și au remedii diferite.
Primul este cel mai ușor de verificat: serverul sau pluginul au oferit vreodată ruta? Un backend care nu a primit niciodată prefixul nu îl poate instala, iar un script auxiliar nu poate inventa o accesibilitate pe care partenerul nu a descris-o niciodată. Al doilea este politica profilului, care poate suprima rute pe care conexiunea le-ar lua altfel. Al treilea este un tabel sau o regulă, care poate ține ruta într-un loc în care interogarea implicită nu se uită niciodată.
Un al patrulea proprietar sunteți dumneavoastră, mai târziu: un script care adaugă ruta la conectare dar nu o elimină la deconectare. Asta produce un prefix care supraviețuiește tunelului, indică o interfață moartă și încurcă următoarea persoană care depanează mașina.
Citiți profilul înainte de a adăuga ceva
Începeți cu proprietățile conexiunii salvate. Citiți-le fără a vărsa secrete și folosiți UUID-ul dacă numele profilului este ambiguu.
nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office
vpn.service-type vă spune ce backend deține conexiunea, iar asta contează pentru că datele pluginului sunt specifice backendului. O cheie acceptată de un plugin nu este o instrucțiune acceptată de altul, așa că un fragment copiat din documentația altui client nu dovedește nimic.
ipv4.ignore-auto-routes și ipv4.never-default răspund la întrebări diferite. Primul poate respinge rute pe care conexiunea le-ar lua altfel automat, iar al doilea controlează dacă profilul poate deveni ruta implicită. Un profil care ignoră rutele automate și nu se bazează pe nimic altceva se va conecta curat și nu va instala aproape nimic.
ip -4 rule show
ip -4 route show table all
Aceste două comenzi rezolvă a treia posibilitate. Căutați prefixul în fiecare tabel, nu doar în main, și verificați dacă o regulă de politică trimite interogarea relevantă în altă parte. Dacă prefixul este într-un alt tabel și nimic nu îl interoghează, nu aveți o rută lipsă; aveți o interogare care nu ajunge niciodată la ea.
Ce nu poate repara un script
Adăugarea unui script auxiliar îi dă vpn.data din NetworkManager un program de executat. Este un mecanism real și este cel greșit pentru majoritatea acestor cazuri, pentru că scriptul primește controlul după ce politica profilului a decis deja ce să accepte.
script-security din OpenVPN este cealaltă confuzie recurentă. Este o setare OpenVPN care stabilește ce scripturi poate executa clientul și ce poate pune în mediul lor; nivelul 3 permite transmiterea acreditărilor prin mediu, ceea ce este o decizie despre tratarea secretelor, nu o corecție de rutare. Lipirea ei într-un profil al cărui backend nu este OpenVPN, sau ridicarea ei când niciun script nu are nevoie de ea, adaugă expunere fără a adăuga o rută.
Apoi este reflexul de repornire. Repornirea serviciului NetworkManager desființează și reconstruiește fiecare legătură gestionată, inclusiv pe cea prin care sunteți conectat dacă lucrați de la distanță. Este o acțiune perturbatoare, nu un diagnostic inofensiv, iar pe un server poate fi diferența dintre o sesiune care supraviețuiește și una care nu.
Decizia, în ordine
Puneți trei întrebări în ordine. Partenerul a furnizat prefixul, ceea ce va arăta jurnalul backendului sau propria ieșire de stare? Dacă da, profilul este configurat să accepte și să instaleze rute, sau le suprimă? Dacă ruta există undeva, calea de interogare este corectă pentru traficul pe care îl testați?
Numai când primul răspuns este da, al doilea este da și al treilea este corect, un script suplimentar devine justificabil, și chiar și atunci ar trebui să întrebați dacă backendul suportă ruta nativ. Referința setărilor VPN documentează service-type și dicționarul de date specific pluginului, și de acolo trebuie început înainte de a presupune că o cheie există.
După o corecție aprobată, reconectați-vă și testați destinația după adresă și apoi după nume, apoi deconectați-vă și reconectați-vă pentru a confirma că starea este repetabilă. Un proprietar, un tabel și o rută care dispare odată cu tunelul este rezultatul care merită.