Sinasabi ng VPN na konektado, pero patay na ang default na ruta

Iniulat ng client na konektado ito, mukhang normal ang icon sa tray, at walang naglo-load. Nagsimula ito kaagad pagkatapos mong lumipat mula Wi-Fi patungong kable, o kaagad pagkatapos matapos ang isang pag-upgrade ng distribusyon. Ang nasira ay hindi ang profile kundi ang estado na itinayo para sa dating base na koneksyon. Mayroon pa ring default na ruta ang kernel na nakaturo sa isang tunnel device na walang nagmamay-ari, o naglilista pa rin ang resolver ng mga server sa isang link na nawala na. Pareho ang hitsura ng dalawang pagkabigo sa isang patay na network at pareho silang maaayos sa lugar.

Mali na ang mga lumang piraso bago mo pa ito napansin. Ang pagbunot ng kable ay ginawa lang silang nakikita.

Tanungin ang kernel kung saan pupunta ang isang packet

Mahirap basahin ang mga listahan ng ruta dahil inililista nila lahat ng alam ng system, kasama ang mga entry na hindi na nalalapat. Sinasagot ng ruta lookup ang tanging tanong na sulit itanong: aling device ang nagdadala ng partikular na packet na ito ngayon. Kung pinangalanan ng sagot ang isang tunnel device, gagamitin ito ng kernel kahit walang buhay na proseso ng client sa likod nito, at mahuhulog ang packet sa isang interface na walang nag-aalaga. Kung pinangalanan ng sagot ang Ethernet adapter habang iginiit ng client na aktibo ito, umiiral ang tunnel pero nawala ang pagpili, na siyang karaniwang resulta ng paglipat mula wireless patungong kable.

Patakbuhin ang lookup nang dalawang beses, isang beses para sa pampublikong address at isang beses para sa panloob, dahil ang patakaran ng split tunnel ay maaaring mag-ruta ng isa nang tapat at ihulog ang isa.

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

Hinihawakan din ng resolver ang patay na link

Sa isang host na may systemd-resolved, kabilang ang mga DNS server sa mga link at hindi sa isang pandaigdigang listahan. Ang isang VPN link na bumagsak ay maaaring manatiling nakarehistro kasama ang mga server nito nang ilang sandali, at pagkatapos ay naghihintay ang bawat lookup sa isang address na hindi kailanman sasagot. Ang pagkaantala na iyon ay parang patay na network at nagpapapunta sa mga tao sa mga ruta habang maayos naman ang ruta.

resolvectl status
resolvectl query intranet.example.com

Basahin ang mga bloke bawat link at tukuyin kung aling link ang nagmamay-ari ng domain na pinag-uusapan. Ang isang tunnel na nakaangat pero hindi nagmamay-ari ng panloob na domain ay nagpapasa ng mga panloob na pangalan sa pampublikong resolver, at ang sintomas ay hindi makikilala mula sa isang depekto sa routing.

Ayusin ang rehistro, hindi /etc/resolv.conf. Sa kasalukuyang mga install ng Ubuntu at Fedora ang landas na iyon ay isang symbolic link patungo sa runtime state ng resolver, kaya ang isang pagbabago ay hindi pinapansin o nasasapawan sa susunod na kaganapan sa network.

Hindi kailanman nagsisimula nang mag-isa ang isang VPN

Itinataas ng NetworkManager ang isang VPN sa ibabaw ng isang base na koneksyon, at natututuhan nito kung alin ang susundin mula sa connection.secondaries sa base na iyon. sanggunian ng mga setting ng koneksyon malinaw na sinasabi na ang autoconnect ay hindi ipinatupad para sa mga VPN profile. Iyon ang buong mekanismo sa likod ng ganitong uri ng pagkabigo: baguhin ang base, at ang VPN ay kailangang i-pares muli o i-activate muli nang manu-mano.

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

Kapag ipinakita ng aktibong listahan ang base na walang VPN, hindi talaga aktibo ang tunnel at hindi kailanman na-install ang ruta sa halip na naiwang luma. Kapag nagrereklamo ang activation na walang source na koneksyon, nawala ang base na kinalakipan nito, kaya ayusin muna ang base o ang pagpapares at huminto sa muling pagsubok sa VPN.

Maaaring maghulog ng mga setting ang isang upgrade nang walang mensahe

Pinapalitan ng pag-upgrade ng isang distribusyon ang client at madalas ang plugin nito sa NetworkManager, habang pinapanatili ng naka-save na profile ang mga pangalan ng property na ginamit noong isinulat ito. Anumang hindi na kinikilala ng bagong plugin ay tahimik na nilalaktawan. Nag-a-activate pa rin ang profile at lumalabas pa rin ang device, pero ang rutang dating kasama nito ay hindi na dumarating.

Gumagalaw din ang mga hook na isinulat sa kamay. Ang isang script na nag-install ng ruta sa isang hulaang sandali ng lumang pagkakasunod-sunod ay maaaring tumakbo na bago pa umiral ang interface, o pagkatapos nang mag-time out ang client.

Ihambing ang buhay na profile sa plugin na aktwal na mayroon ka, hindi sa pag-uugaling natatandaan mo. Kung may key na nawala sa dokumentasyon, ilipat ang trabaho sa isang dispatcher script o sa isang sinusuportahang kapalit sa halip na ibalik ang lumang property.

Tatlong estado, tatlong magkaibang pag-aayos

Magpasya kung aling estado ka naroon bago humawak ng kahit ano, dahil sinisira ng restart ang ebidensya at bumabalik ang depekto sa susunod na pagbabago sa network.

Tapusin sa isang lookup para sa pampublikong address, isa para sa panloob na address at isang query ng pangalan. Kung gumagana ang mga address at hindi ang pangalan, ang natitirang depekto ay saklaw ng domain sa resolver, at ang talahanayan ng ruta ay hindi kailanman naging problema.