VPN pravi, da je povezan, vendar je privzeta pot mrtva

Odjemalec sporoča povezavo, ikona v sistemski vrstici je videti običajna in nič se ne naloži. Začelo se je takoj po prehodu z Wi-Fi na kabel ali takoj po končani nadgradnji distribucije. Ni se pokvaril profil, ampak stanje, zgrajeno za prejšnjo osnovno povezavo. Jedro ima še vedno privzeto pot, ki kaže na tunelsko napravo, ki je nihče ne poseduje, ali razreševalnik še vedno navaja strežnike na povezavi, ki je izginila. Obe napaki sta videti kot mrtvo omrežje in obe je mogoče popraviti na mestu.

Zastareli deli so bili napačni že prej, preden ste jih opazili. Izklop kabla jih je le naredil vidne.

Vprašajte jedro, kam bi šel paket

Sezname poti je težko brati, ker naštevajo vse, kar sistem pozna, vključno z vnosi, ki ne veljajo več. Iskanje poti odgovori na edino vprašanje, ki se ga je vredno vprašati: katera naprava prav zdaj nosi ta konkretni paket. Če odgovor navede tunelsko napravo, jo bo jedro uporabilo, tudi če za njo ni živega odjemalskega procesa, in paket pade v vmesnik, ki ga nihče ne vzdržuje. Če odgovor navede vmesnik Ethernet, medtem ko odjemalec vztraja, da je povezava aktivna, tunel obstaja, a je izgubil izbiro, kar je običajen izid prehoda z brezžičnega na žično omrežje.

Zaženite iskanje dvakrat, enkrat za javni naslov in enkrat za notranji, ker lahko politika razdeljenega tunela enega usmeri pošteno, drugega pa spusti.

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

Razreševalnik zadrži tudi mrtvo povezavo

Na gostitelju s systemd-resolved pripadajo strežniki DNS povezavam in ne enemu globalnemu seznamu. Povezava VPN, ki je padla, lahko nekaj časa ostane registrirana s svojimi strežniki, in takrat vsako iskanje čaka na naslov, ki ne bo nikoli odgovoril. Ta zamuda se občuti kot mrtvo omrežje in pošlje ljudi gledat poti, ko je pot v redu.

resolvectl status
resolvectl query intranet.example.com

Preberite bloke po povezavah in ugotovite, katera povezava ima zadevno domeno. Tunel, ki je dvignjen, a ni lastnik notranje domene, posreduje notranja imena javnemu razreševalniku, in simptom se ne razlikuje od napake pri usmerjanju.

Popravite registracijo, ne /etc/resolv.conf. V trenutnih namestitvah Ubuntu in Fedore je ta pot simbolna povezava na izvajalno stanje razreševalnika, zato je sprememba bodisi prezrta bodisi prepisana ob naslednjem omrežnem dogodku.

VPN se nikoli ne zažene sam

NetworkManager dvigne VPN nad osnovno povezavo in se nauči, kateri slediti, iz connection.secondaries na tej osnovi. Referenca za nastavitve povezave izrecno navaja, da samodejno povezovanje za profile VPN ni implementirano. To je celoten mehanizem za to vrsto napak: spremenite osnovo in VPN je treba znova seznaniti ali ročno znova aktivirati.

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

Ko aktivni seznam pokaže osnovo brez VPN, tunel sploh ni aktiven in pot ni bila nikoli nameščena, namesto da bi ostala zastarela. Ko se aktivacija pritožuje, da ni izvorne povezave, je osnova, s katero je bila seznanjena, izginila, zato najprej popravite osnovo ali seznanitev in prenehajte znova poskušati VPN.

Nadgradnja lahko spusti nastavitve brez sporočila

Nadgradnja distribucije zamenja odjemalca in pogosto njegov vtičnik NetworkManager, medtem ko shranjeni profil obdrži imena lastnosti, s katerimi je bil zapisan. Vse, česar novi vtičnik ne prepozna več, se tiho preskoči. Profil se še vedno aktivira in naprava se še vedno pojavi, a pot, ki je včasih prihajala z njim, ne pride več.

Ročno napisani kavlji se tudi premaknejo. Skript, ki je namestil pot v predvidljivem trenutku starega zaporedja, lahko zdaj teče pred obstojem vmesnika ali potem, ko je odjemalec že potekel.

Primerjajte živi profil z vtičnikom, ki ga res imate, in ne z vedenjem, ki se ga spomnite. Če je ključ izginil iz dokumentacije, premaknite delo v skript razpošiljatelja ali v podprto zamenjavo, namesto da obnovite staro lastnost.

Tri stanja, tri različna popravila

Odločite, v katerem stanju ste, preden se česar koli dotaknete, ker ponovni zagon uniči dokaze in napaka se vrne ob naslednji omrežni spremembi.

Končajte z enim iskanjem za javni naslov, enim za notranji naslov in eno poizvedbo imena. Če naslovi delujejo, ime pa ne, je preostala napaka obseg domene v razreševalniku, in tabela poti nikoli ni bila težava.