VPN zegt verbonden maar er gaat niets door: twee plekken om te kijken

Een tunnel kan melden dat hij verbonden is terwijl er niets aankomt, en die twee feiten staan op verschillende plekken. Het ene is de routetabel, die pakketten nog naar een apparaat kan sturen dat niemand bezit. Het andere is de resolver, die nog een server kan vermelden op een link die weg is. De netwerkwijziging heeft het profiel niet beschadigd, zij heeft de toestand van de vorige verbinding verweesd achtergelaten, en de reparatie hangt ervan af naar welke van de twee je echt kijkt.

Vraag eerst de kernel welk apparaat hij zou gebruiken

Een routelijst laat zien wat bestaat; een routeopzoeking laat zien wat er zou gebeuren. Vraag naar een openbaar adres en lees de apparaatnaam in het antwoord, want dat ene veld bepaalt of het pakket ergens nuttig aankomt. Noemt het antwoord een tunnelapparaat, dan geeft de kernel de pakketten daaraan, ook als er achter die interface geen clientproces meer draait. Noemt het antwoord de fysieke adapter terwijl de client zegt verbonden te zijn, dan staat de tunnel omhoog en is hij alleen niet het gekozen pad.

Het tweede geval is het gebruikelijke nadat een kabel de draadloze verbinding vervangt, en het presenteert zich als een kapotte VPN.

ip route show default
ip route get 203.0.113.9

Lees daarna de standaardregels, want een route van de vorige basisverbinding kan een linkwissel overleven en vóór de nieuwe staan. Een standaardroute via een apparaat dat plat ligt is erger dan geen standaardroute, omdat de kernel hem nog steeds verkiest. Let op de metriek naast elke regel, want die volgorde verklaart de voorkeur sneller dan de interfacenamen.

Lees daarna de resolver per link, niet per bestand

Naamresolutie draagt haar eigen toestand en haar eigen veroudering. Een resolver die DNS-servers per link vermeldt, houdt de servers van een tunnellink die platligt maar nog geregistreerd is, en elke opzoeking wacht dan op een server die niet antwoordt. Het symptoom is een netwerk dat dood voelt terwijl de routetabel perfect lijkt.

Bekijk de toestand per link in plaats van het bestand, want op veel distributies is dat bestand een symbolische koppeling naar de resolver en bewerken doet niets of wordt snel overschreven. Kijk welke link welke servers en welk zoekdomein bezit, en vraag dan of de tunnellink nog geregistreerd zou moeten zijn. Als dat niet zo is, deactiveer dan de verbinding die hem bezit in plaats van gegenereerde toestand met de hand te bewerken. Een naam die oplost terwijl de routeopzoeking pakketten elders heen stuurt, is een derde en aparte fout.

resolvectl status
resolvectl query app.internal.example

Als adressen oplossen en verbindingen falen, is de resolver in orde en de route niet. Als adressen helemaal niet oplossen, is dit de juiste plek om te beginnen.

Hoe een verouderde route de wijziging overleeft

De client bezit het netwerk niet alleen. Op een NetworkManager-host wordt een VPN-profiel geactiveerd bovenop een basisverbinding, en de verbindingsinstellingen laten die basis de VPN noemen die hem moet volgen. Wanneer de basis verandert omdat een ander profiel de voorkeur krijgt, volgt de tunnel naar de nieuwe basis of blijft hij zonder een achter.

Een VPN-profiel brengt zichzelf niet omhoog, dus de koppeling is veel belangrijker dan de autoconnect-voorkeur van het profiel zelf.

Lees de actieve lijst en noteer welke basis omhoog staat voordat je de tunnel aanraakt. Staat de basis erin en de tunnel niet, dan ontbreekt de route in plaats van verouderd te zijn en is de oplossing activeren. Klaagt het activeren van de tunnel dat er geen bronverbinding bestaat, dan is de basis waarmee hij gekoppeld was weg, dus breng die eerst omhoog of repareer de koppeling in plaats van de tunnel opnieuw te proberen. Een profiel zonder ouder opnieuw proberen levert elke keer dezelfde fout op, wat een nuttig signaal is en geen last.

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

Verouderde toestand onderscheiden van een ontbrekende ouder

Drie toestanden verklaren bijna elk rapport, en elk ervan vraagt een andere reparatie. Een standaardroute via een apparaat dat nog bestaat maar de tunnel niet meer draagt, is verouderde toestand, opgeruimd door de regel te verwijderen of het verantwoordelijke profiel te herstarten. Een tunnelapparaat waarvan het clientproces is verdwenen, is een opruimfout, dus het afsluitpad verdient de aandacht en niet de routetabel. Helemaal geen tunnelapparaat betekent dat de ouder of de koppeling ontbreekt en dat de routetabel er nooit bij betrokken was.

Herstarten verbergt welke van de drie je had, en daarom voelt het precies als een oplossing.

Vraag na de reparatie de kernel om een openbaar en een intern adres, en vraag daarna een interne naam op. Als het adres werkt en de naam niet, dan heb je een domeinbereikprobleem in de resolver gevonden en geen routeringsprobleem. Noteer welke toestand je vond, want de volgende netwerkwijziging reproduceert degene die je met rust hebt gelaten.