VPN seier tilkobla, men ingenting blir ruta: to stader å sjå

Ein tunnel kan melde seg tilkobla medan ingenting når han, og dei to fakta bur på ulike stader. Det eine er rutetabellen, som framleis kan sende pakkar til ei eining som ingen eig. Det andre er resolveren, som framleis kan liste ein server på ei lenke som er borte. Nettverksendringa skadde ikkje profilen, ho gjorde tilstanden som høyrde til den førre tilkoblinga foreldrelaus, og reparasjonen avheng av kva av dei to du faktisk ser på.

Spør først kjernen kva eining han ville bruke

Ei ruteliste viser kva som finst; eit ruteoppslag viser kva som ville skje. Spør om ein offentleg adresse og les einingsnamnet i svaret, for det eine feltet avgjer om pakken når noko nyttig. Når svaret nemner ei tunneleining, gjev kjernen pakkane dit sjølv om ingen klientprosess framleis køyrer bak det grensesnittet. Når svaret nemner den fysiske adapteren medan klienten hevdar å vere tilkobla, er tunnelen oppe og berre ikkje den valde vegen.

Det andre tilfellet er det vanlege etter at ein kabel har erstatta trådlaust, og det presenterer seg som ein øydelagd VPN.

ip route show default
ip route get 203.0.113.9

Les standardoppføringane deretter, sidan ei rute lagd til av den førre basistilkoblinga kan overleve eit lenkebytte og stå framom den nye. Ei standardrute gjennom ei eining som er nede er verre enn inga standardrute, fordi kjernen framleis føretrekkjer henne. Legg merke til metrikken ved kvar oppføring, for den rekkjefølgja forklarer preferansen raskare enn grensesnittnamna.

Deretter les resolveren per lenke, ikkje per fil

Namneoppslag ber sin eigen tilstand og si eiga utdatering. Ein resolver som listar DNS-serverar per lenke behald serverane til ei tunnellenke som er nede men framleis registrert, og kvart oppslag ventar då på ein server som ikkje vil svare. Symptomet er eit nettverk som kjennest dødt medan rutetabellen ser perfekt ut.

Undersøk tilstanden per lenke i staden for fila, for på mange distribusjonar er fila ei symbolsk lenke inn i resolveren, og å redigere henne gjer anten ingenting eller blir raskt overstyrt. Sjå kva lenke som eig kva serverar og kva søkjedomene, og spør så om tunnellenka i det heile framleis bør vere registrert. Viss ikkje, deaktiver tilkoblinga som eig henne i staden for å redigere generert tilstand for hand. Eit namn som blir løyst opp medan ruteoppslaget sender pakkane ein annan stad, er ein tredje og separat feil.

resolvectl status
resolvectl query app.internal.example

Viss adresser blir løyste opp og tilkoblingar feilar, er resolveren i orden og ruta ikkje. Viss adresser ikkje blir løyste opp i det heile, er dette rett stad å byrje.

Korleis ei utdatert rute overlever endringa

Klienten eig ikkje nettverket åleine. På ein NetworkManager-vert blir ein VPN-profil aktivert oppå ei basistilkobling, og tilkoblingsinnstillingane lèt den basen namngje VPN-en som skal følgje han. Når basen blir endra fordi ein annan profil blir føretrekt, følgjer tunnelen over til den nye basen eller blir ståande utan nokon.

Ein VPN-profil tar ikkje opp seg sjølv, så parkoplinga tyder langt meir enn profilens eigen autoconnect-innstilling.

Les den aktive lista og noter kva base som er oppe før du rører tunnelen. Viss basen står der og tunnelen ikkje, manglar ruta snarare enn å vere utdatert, og rettinga er aktivering. Viss aktiveringa av tunnelen klagar over at inga kjeldeilkobling finst, er basen han var parkopla med borte, så få han opp først eller reparer parkoplinga i staden for å prøve tunnelen igjen. Å prøve ein profil på nytt der forelderen manglar gjev same feil kvar gong, noko som er eit nyttig signal og ikkje ei plage.

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

Skilje utdatert tilstand frå ein manglande forelder

Tre tilstandar forklarer nesten kvar rapport, og kvar krev si eiga reparasjon. Ei standardrute gjennom ei eining som framleis finst men ikkje lenger ber tunnelen, er utdatert tilstand, rydda anten ved å slette oppføringa eller ved å starte profilen som er ansvarleg på nytt. Ei tunneleining der klientprosessen har forsvunne, er ein oppryddingsfeil, så fråkoblingsvegen fortener merksemda og ikkje rutetabellen. Ingen tunneleining i det heile tyder at forelderen eller parkoplinga manglar og at rutetabellen aldri var involvert.

Ein omstart skjuler kva av dei tre du hadde, og det er nettopp difor det kjennest som ei retting.

Etter reparasjonen, spør kjernen om ein offentleg og ein intern adresse, og slå deretter opp eit internt namn. Når adressa verkar og namnet ikkje, har du funne eit domeneomfangproblem i resolveren og ikkje eit ruteproblem. Noter kva tilstand du fann, for den neste nettverksendringa vil gjenskape den du lét vere.