VPN ütleb ühendatud, aga midagi ei marsruutu: kaks kohta, kust vaadata
Marsruudi valik ja resolveri registreerimine vananevad erineval moel. Küsi esmalt tuumalt, seejärel lingipõhiselt resolverilt ja lõpuks kontrolli ülemühendust.
Tunnel võib teatada, et on ühendatud, samal ajal kui miski selleni ei jõua, ja need kaks fakti asuvad eri kohtades. Üks on marsruutimistabel, mis võib ikka saata pakette seadmele, mida keegi ei oma. Teine on resolver, mis võib ikka loetleda serverit lingil, mis on kadunud. Võrgu muudatus ei kahjustanud profiili, see jättis eelmise ühenduse juurde kuulunud oleku orvuks, ja parandus sõltub sellest, kumba kahest sa tegelikult vaatad.
Küsi esmalt tuumalt, millist seadet ta kasutaks
Marsruutide loend näitab, mis on olemas; marsruudi otsing näitab, mis juhtuks. Küsi avaliku aadressi kohta ja loe vastusest seadme nimi, sest see üks väli otsustab, kas pakett jõuab kuhugi kasulikku. Kui vastus nimetab tunneliseadet, annab tuum paketid sinna, isegi kui selle liidese taga ei tööta enam ükski kliendiprotsess. Kui vastus nimetab füüsilist adapterit, samal ajal kui klient väidab end olevat ühendatud, on tunnel püsti ja lihtsalt ei ole valitud tee.
Teine juhtum on tavaline pärast seda, kui kaabel asendab juhtmevaba, ja see esineb katkise VPN-ina.
ip route show default
ip route get 203.0.113.9Loe seejärel vaikimisi kirjeid, sest eelmise põhiühenduse lisatud marsruut võib lingi vahetuse üle elada ja seista uue ees. Vaikimisi marsruut seadme kaudu, mis on maas, on hullem kui üldse mitte vaikimisi marsruut, sest tuum eelistab seda ikka. Pane tähele iga kirje kõrval olevat meetrikat, sest see järjestus selgitab eelistust kiiremini kui liideste nimed.
Seejärel loe resolverit lingi kaupa, mitte faili kaupa
Nimede lahendamine kannab oma olekut ja oma vananemist. Resolver, mis loetleb DNS-serverid lingi kaupa, hoiab alles maas, kuid endiselt registreeritud tunnelilingi serverid, ja iga päring ootab siis serverit, mis ei vasta. Sümptom on võrk, mis tundub surnud, samal ajal kui marsruutimistabel näeb täiuslik välja.
Uuri olekut lingi kaupa, mitte faili, sest paljudes distributsioonides on see fail sümboolne link resolverisse ja selle muutmine kas ei tee midagi või kirjutatakse kiiresti üle. Vaata, milline link omab milliseid servereid ja millist otsingudomeeni, ja küsi siis, kas tunnelilink peaks üldse veel registreeritud olema. Kui ei peaks, lülita välja ühendus, mis seda omab, selle asemel et genereeritud olekut käsitsi muuta. Nimi, mis laheneb, samal ajal kui marsruudiotsing saadab paketid mujale, on kolmas ja eraldi viga.
resolvectl status
resolvectl query app.internal.exampleKui aadressid lahenevad ja ühendused ebaõnnestuvad, on resolver korras ja marsruut mitte. Kui aadressid ei lahene üldse, on see õige koht alustamiseks.
Kuidas vananenud marsruut muudatuse üle elab
Klient ei oma võrku üksi. NetworkManager-hostis aktiveeritakse VPN-profiil põhiühenduse peal ja ühenduse seaded lasevad sellel põhiühendusel nimetada VPN-i, mis peaks sellele järgnema. Kui põhiühendus muutub, sest eelistatuks saab teine profiil, järgneb tunnel uuele põhiühendusele või jääb ilma ühestki.
VPN-profiil ei tõsta end ise üles, seega sidumine loeb palju rohkem kui profiili enda autoconnect-eelistus.
Loe aktiivset loendit ja pane tähele, milline põhiühendus on püsti, enne kui tunnelit puudutad. Kui põhiühendus on loendis ja tunnel mitte, on marsruut puudu, mitte vananenud, ja parandus on aktiveerimine. Kui tunneli aktiveerimine kurdab, et lähteühendust ei ole, on põhiühendus, millega see oli seotud, kadunud, seega tõsta see esmalt üles või paranda sidumine, selle asemel et tunnelit uuesti proovida. Profiili uuesti proovimine, mille vanem puudub, annab iga kord sama vea, mis on kasulik signaal, mitte tüütus.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpnErista vananenud olek puuduvast vanemast
Kolm olekut seletavad peaaegu iga raportit ja igaüks neist nõuab erinevat parandust. Vaikimisi marsruut seadme kaudu, mis on ikka olemas, kuid ei kanna enam tunnelit, on vananenud olek, mida puhastatakse kas kirje kustutamisega või vastutava profiili uuesti käivitamisega. Tunneliseade, mille kliendiprotsess on kadunud, on koristamise tõrge, seega tähelepanu väärib katkestustee, mitte marsruutimistabel. Üldse tunneliseadet ei ole tähendab, et vanem või sidumine on puudu ja et marsruutimistabel ei olnud kunagi asjasse kaasatud.
Taaskäivitus varjab, milline kolmest sul oli, ja täpselt sellepärast tundub see parandusena.
Pärast parandust küsi tuumalt ühte avalikku ja ühte sisemist aadressi ning seejärel päri sisemist nime. Kui aadress töötab ja nimi mitte, oled leidnud domeeniulatuse probleemi resolveris, mitte marsruutimisprobleemi. Kirjuta üles, millise oleku leidsid, sest järgmine võrgu muudatus taastoodab selle, mille rahule jätsid.