VPN zegt verbonden, maar de standaardroute is dood

De client meldt verbonden, het pictogram in het systeemvak ziet er normaal uit, en niets laadt. Het begon direct nadat je van Wi-Fi naar een kabel ging, of direct nadat een distributie-upgrade klaar was. Wat stuk is, is niet het profiel maar de toestand die voor de vorige basisverbinding werd opgebouwd. De kernel heeft nog een standaardroute naar een tunnelapparaat dat niemand bezit, of de resolver vermeldt nog servers op een link die verdwenen is. Beide storingen lijken op een dood netwerk en beide zijn ter plaatse te repareren.

De verouderde stukken waren al fout voordat je het merkte. Een kabel lostrekken maakte ze alleen zichtbaar.

Vraag de kernel waar een pakket heen zou gaan

Routelijsten zijn moeilijk te lezen omdat ze alles opsommen wat het systeem kent, inclusief vermeldingen die niet meer gelden. Een routeopzoeking beantwoordt de enige vraag die het stellen waard is: welk apparaat draagt dit specifieke pakket op dit moment. Als het antwoord een tunnelapparaat noemt, gebruikt de kernel het ook al is er geen levend clientproces achter, en het pakket valt in een interface die niemand onderhoudt. Als het antwoord de Ethernet-adapter noemt terwijl de client volhoudt dat de verbinding actief is, bestaat de tunnel maar heeft hij de selectie verloren, wat het gebruikelijke resultaat is van de overstap van draadloos naar bedraad.

Voer de opzoeking twee keer uit, één keer voor een openbaar adres en één keer voor een intern, omdat een split-tunnelbeleid het ene eerlijk kan routeren en het andere kan laten vallen.

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

De resolver houdt ook de dode link vast

Op een host met systemd-resolved horen DNS-servers bij links en niet bij één globale lijst. Een VPN-link die is weggevallen kan een tijdje geregistreerd blijven met zijn servers, en dan wacht elke opzoeking op een adres dat nooit zal antwoorden. Die vertraging voelt als een dood netwerk en stuurt mensen naar de routes terwijl de route in orde is.

resolvectl status
resolvectl query intranet.example.com

Lees de blokken per link en bepaal welke link het domein in kwestie bezit. Een tunnel die actief is maar niet de eigenaar van het interne domein is, stuurt interne namen door naar de openbare resolver, en het symptoom is niet te onderscheiden van een routeringsfout.

Repareer de registratie en niet /etc/resolv.conf. Op huidige Ubuntu- en Fedora-installaties is dat pad een symbolische link naar de runtime-toestand van de resolver, dus een wijziging wordt of genegeerd of bij de volgende netwerkgebeurtenis overschreven.

Een VPN start nooit vanzelf

NetworkManager brengt een VPN boven op een basisverbinding om, en het leert welke het moet volgen uit connection.secondaries op die basis. De referentie voor verbindingsinstellingen zegt uitdrukkelijk dat automatisch verbinden niet is geïmplementeerd voor VPN-profielen. Dat is het hele mechanisme achter deze klasse van storingen: verander de basis, en de VPN moet opnieuw worden gepaard of handmatig opnieuw worden geactiveerd.

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

Wanneer de actieve lijst de basis zonder de VPN toont, is de tunnel helemaal niet actief en is de route nooit geïnstalleerd in plaats van verouderd achtergelaten. Wanneer de activering klaagt dat er geen bronverbinding bestaat, is de basis waarmee hij was gepaard verdwenen, dus repareer eerst de basis of de paring en stop met opnieuw proberen van de VPN.

Een upgrade kan instellingen zonder bericht laten vallen

Een distributie upgraden vervangt de client en vaak zijn NetworkManager-plugin, terwijl het opgeslagen profiel de eigenschapsnamen houdt waarmee het is geschreven. Alles wat de nieuwe plugin niet meer herkent, wordt stil overgeslagen. Het profiel wordt nog steeds geactiveerd en het apparaat verschijnt nog steeds, maar de route die vroeger meekwam, komt nooit meer.

Handgeschreven hooks verschuiven ook. Een script dat op een voorspelbaar moment in de oude volgorde een route installeerde, kan nu draaien voordat de interface bestaat, of nadat de client al een time-out heeft gehad.

Vergelijk het levende profiel met de plugin die je werkelijk hebt, in plaats van met het gedrag dat je je herinnert. Als een sleutel uit de documentatie is verdwenen, verplaats het werk naar een dispatcher-script of een ondersteunde vervanging in plaats van de oude eigenschap te herstellen.

Drie toestanden, drie verschillende reparaties

Bepaal in welke toestand je bent voordat je iets aanraakt, want een herstart vernietigt het bewijs en de fout komt terug bij de volgende netwerkwijziging.

Sluit af met één opzoeking voor een openbaar adres, één voor een intern adres en één naamquery. Als de adressen werken en de naam niet, is de resterende fout domeinbereik in de resolver, en de routetabel was nooit het probleem.