Sabi ng VPN konektado pero walang naruruta: dalawang lugar na titingnan

Maaaring mag-ulat ng konektado ang isang tunnel habang walang nakakaabot dito, at magkaibang lugar ang tinitirhan ng dalawang katotohanang iyon. Isa ang talahanayan ng ruta, na maaari pa ring magpadala ng mga packet sa isang device na wala namang nagmamay-ari. Ang isa pa ay ang resolver, na maaari pa ring maglista ng server sa isang link na wala na. Hindi sinira ng pagbabago sa network ang profile, inulila nito ang estado na pag-aari ng naunang koneksyon, at ang pag-aayos ay nakasalalay sa kung alin sa dalawa ang talagang tinitingnan mo.

Una, tanungin ang kernel kung aling device ang gagamitin nito

Ipinapakita ng listahan ng ruta kung ano ang umiiral; ipinapakita ng paghahanap ng ruta kung ano ang mangyayari. Magtanong tungkol sa isang pampublikong address at basahin ang pangalan ng device sa sagot, dahil ang nag-iisang field na iyon ang nagpapasya kung makakarating ang packet sa kahit saan na pakikinabangan. Kapag pinangalanan ng sagot ang isang tunnel device, ibibigay ng kernel ang mga packet dito kahit wala nang client process na tumatakbo sa likod ng interface na iyon. Kapag pinangalanan ng sagot ang pisikal na adapter habang sinasabi ng client na konektado ito, nakataas ang tunnel at hindi lamang ito ang piniling landas.

Ang ikalawang kaso ang karaniwan pagkatapos palitan ng kable ang wireless, at nagpapakita ito bilang sirang VPN.

ip route show default
ip route get 203.0.113.9

Basahin sa susunod ang mga default na entry, dahil ang rutang idinagdag ng naunang base na koneksyon ay maaaring mabuhay nang mas matagal kaysa sa pagbabago ng link at tumayo sa harap ng bago. Ang default na ruta sa pamamagitan ng isang device na patay ay mas masahol kaysa sa walang default na ruta, dahil pinipili pa rin ito ng kernel. Pansinin ang metric sa tabi ng bawat entry, dahil ipinapaliwanag ng pagkakasunod-sunod na iyon ang kagustuhan nang mas mabilis kaysa sa mga pangalan ng interface.

Pagkatapos, basahin ang resolver bawat link, hindi bawat file

May sariling estado at sariling pagkalipas ang paglutas ng pangalan. Ang resolver na naglilista ng mga DNS server bawat link ay nagpapanatili ng mga server ng isang tunnel link na patay pero nakarehistro pa rin, at ang bawat paghahanap ay naghihintay noon sa isang server na hindi sasagot. Ang sintomas ay isang network na parang patay habang perpekto ang tingin sa talahanayan ng ruta.

Suriin ang estado bawat link kaysa sa file, dahil sa maraming distribusyon ang file na iyon ay isang symbolic link papasok sa resolver at ang pag-edit dito ay maaaring walang ginagawa o mabilis na nao-overwrite. Tingnan kung aling link ang nagmamay-ari ng aling server at aling search domain, pagkatapos itanong kung dapat pa bang nakarehistro ang tunnel link. Kung hindi, i-deactivate ang koneksyon na nagmamay-ari nito sa halip na i-edit nang mano-mano ang nabuong estado. Ang pangalang nalulutas habang ang paghahanap ng ruta ay nagpapadala ng mga packet sa ibang lugar ay isang ikatlo at hiwalay na depekto.

resolvectl status
resolvectl query app.internal.example

Kung nalulutas ang mga address at nabibigo ang mga koneksyon, maayos ang resolver at hindi ang ruta. Kung hindi nalulutas ang mga address, ito ang tamang lugar na simulan.

Paano nakakaligtas ang lipas na ruta sa pagbabago

Hindi nagmamay-ari ang client ng network nang mag-isa. Sa isang host na may NetworkManager, ang profile ng VPN ay ina-activate sa ibabaw ng isang base na koneksyon, at pinapayagan ng mga setting ng koneksyon ang base na iyon na pangalanan ang VPN na dapat sumunod dito. Kapag nagbago ang base dahil mas pinipili ang ibang profile, sumusunod ang tunnel sa bagong base o naiiwan na wala nito.

Hindi itinataas ng profile ng VPN ang sarili nito, kaya mas mahalaga ang pagpapares kaysa sa sariling kagustuhan sa autoconnect ng profile.

Basahin ang aktibong listahan at tandaan kung aling base ang nakataas bago hawakan ang tunnel. Kung nakalista ang base at wala ang tunnel, kulang ang ruta kaysa lipas, at ang pag-aayos ay activation. Kung nagrereklamo ang pag-activate ng tunnel na walang source na koneksyon, wala na ang base na pinagparesan nito, kaya itaas muna iyon o ayusin ang pagpapares sa halip na subukan muli ang tunnel. Ang paulit-ulit na pagsubok sa isang profile na wala ang magulang ay nagbibigay ng parehong error sa bawat pagkakataon, na kapaki-pakinabang na senyales at hindi abala.

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

Ihiwalay ang lipas na estado sa kulang na magulang

Tatlong estado ang nagpapaliwanag sa halos lahat ng ulat, at bawat isa ay nangangailangan ng ibang pag-aayos. Ang default na ruta sa pamamagitan ng isang device na umiiral pa ngunit hindi na nagdadala ng tunnel ay lipas na estado, nalilinis sa pamamagitan ng pagtanggal ng entry o ng pag-restart ng profile na may pananagutan. Ang isang tunnel device na nawala ang client process ay isang kabiguan sa paglilinis, kaya ang landas ng pag-disconnect ang dapat pansinin at hindi ang talahanayan ng ruta. Walang tunnel device sa lahat ay nangangahulugan na kulang ang magulang o ang pagpapares at hindi kailanman nasangkot ang talahanayan ng ruta.

Itinatago ng pag-reboot kung alin sa tatlo ang naranasan mo, at iyon mismo ang dahilan kung bakit parang pag-aayos ito.

Pagkatapos ng pag-aayos, hilingin sa kernel ang isang pampubliko at isang panloob na address, pagkatapos i-query ang isang panloob na pangalan. Kapag gumagana ang address at hindi ang pangalan, nakakita ka ng problema sa saklaw ng domain sa resolver at hindi problema sa pagruruta. Itala kung aling estado ang natagpuan mo, dahil muling gagawin ng susunod na pagbabago sa network ang iniwan mo.