VPN-ul spune că este conectat, dar ruta implicită este moartă

Clientul raportează conectat, pictograma din tavă arată normal și nimic nu se încarcă. A început imediat după ce ați trecut de la Wi-Fi la cablu sau imediat după ce s-a terminat o actualizare a distribuției. Nu profilul s-a stricat, ci starea construită pentru conexiunea de bază anterioară. Kernelul are încă o rută implicită care indică un dispozitiv de tunel pe care nimeni nu îl deține, sau resolverul încă listează servere pe un link care a dispărut. Ambele defecțiuni arată ca o rețea moartă și ambele pot fi reparate la fața locului.

Piesele învechite erau deja greșite înainte să observați. Scoaterea unui cablu doar le-a făcut vizibile.

Întrebați kernelul încotro ar merge un pachet

Listele de rute sunt greu de citit pentru că enumeră tot ce știe sistemul, inclusiv intrări care nu mai sunt valabile. O căutare de rută răspunde la singura întrebare care merită pusă: ce dispozitiv duce exact acest pachet acum. Dacă răspunsul numește un dispozitiv de tunel, kernelul îl va folosi chiar dacă în spate nu există niciun proces client viu, iar pachetul cade într-o interfață pe care nimeni nu o întreține. Dacă răspunsul numește adaptorul Ethernet în timp ce clientul insistă că legătura este activă, tunelul există dar a pierdut selecția, ceea ce este rezultatul obișnuit al trecerii de la wireless la cablu.

Rulați căutarea de două ori, o dată pentru o adresă publică și o dată pentru una internă, pentru că o politică de tunel divizat poate direcționa una cinstit și poate arunca cealaltă.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Resolverul păstrează și el legătura moartă

Pe un host cu systemd-resolved, serverele DNS aparțin legăturilor și nu unei liste globale. O legătură VPN care a căzut poate rămâne înregistrată cu serverele ei o vreme, iar atunci fiecare căutare așteaptă o adresă care nu va răspunde niciodată. Acea întârziere se simte ca o rețea moartă și îi trimite pe oameni să se uite la rute când ruta este în regulă.

resolvectl status
resolvectl query intranet.example.com

Citiți blocurile pe legături și stabiliți care legătură deține domeniul în cauză. Un tunel care este ridicat dar nu este proprietarul domeniului intern trimite numele interne către resolverul public, iar simptomul nu se poate distinge de o defecțiune de rutare.

Reparați înregistrarea, nu /etc/resolv.conf. În instalările actuale de Ubuntu și Fedora acea cale este o legătură simbolică către starea de execuție a resolverului, așa că o modificare este ignorată sau suprascrisă la următorul eveniment de rețea.

Un VPN nu pornește niciodată singur

NetworkManager ridică un VPN deasupra unei conexiuni de bază și învață pe care să o urmeze din connection.secondaries pe acea bază. Referința setărilor de conexiune spune explicit că conectarea automată nu este implementată pentru profilurile VPN. Acesta este întregul mecanism din spatele acestei clase de defecțiuni: schimbați baza, iar VPN-ul trebuie reîmperecheat sau reactivat manual.

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

Când lista activă arată baza fără VPN, tunelul nu este deloc activ și ruta nu a fost niciodată instalată, în loc să fi rămas învechită. Când activarea se plânge că nu există nicio conexiune sursă, baza cu care fusese împerecheată a dispărut, așa că reparați mai întâi baza sau împerecherea și opriți reîncercarea VPN-ului.

O actualizare poate pierde setări fără niciun mesaj

Actualizarea unei distribuții înlocuiește clientul și adesea modulul său NetworkManager, în timp ce profilul salvat păstrează numele de proprietăți cu care a fost scris. Tot ce modulul nou nu mai recunoaște este sărit în tăcere. Profilul se activează în continuare și dispozitivul apare în continuare, dar ruta care venea altădată cu el nu mai vine.

Cârligele scrise de mână se mută și ele. Un script care instala o rută într-un moment previzibil al vechii secvențe poate rula acum înainte ca interfața să existe, sau după ce clientul a expirat deja.

Comparați profilul viu cu modulul pe care îl aveți de fapt, nu cu comportamentul de care vă amintiți. Dacă o cheie a dispărut din documentație, mutați munca într-un script dispatcher sau într-o înlocuire acceptată, în loc să restaurați vechea proprietate.

Trei stări, trei reparații diferite

Decideți în ce stare sunteți înainte de a atinge ceva, pentru că o repornire distruge dovezile și defecțiunea revine la următoarea schimbare de rețea.

Încheiați cu o căutare pentru o adresă publică, una pentru o adresă internă și o interogare de nume. Dacă adresele funcționează și numele nu, defecțiunea rămasă este domeniul de aplicare din resolver, iar tabela de rute nu a fost niciodată problema.