VPN verbonden maar één dienst faalt: isoleer de fase

„Verbonden“ is het minst informatieve feit in een VPN-ticket. Het legt vast dat twee peers een handshake hebben afgerond, en niets over de opgevraagde naam, de interface waardoor het pakket vertrok, de grootte ervan, of de andere kant het accepteerde. Daarom kan één dienst falen terwijl elke andere toepassing op dezelfde laptop werkt. Doorloop de fasen in volgorde en de eerste die faalt, benoemt het probleem.

Begin bij de naam, niet bij de tunnel

Los op voordat je routeert, want een slecht antwoord maakt elke latere test zinloos. Vraag de naam op bij de systeemresolver en vergelijk dat antwoord met het adres dat de toepassing werkelijk gebruikte. Een privénaam die als openbaar adres terugkomt, betekent dat de query naar een resolver ging die er niets mee te maken heeft. Een naam die niet oplost, is dezelfde categorie, alleen harder.

resolvectl query host.internal
getent hosts host.internal

Browsers met hun eigen instelling voor veilige DNS falen hier terwijl de rest van het systeem werkt. Daarom hoort een klacht die alleen de browser betreft eerst bij deze fase, voordat iemand een route aanraakt. Vergelijk beide commando’s in plaats van één, want getent volgt het NSS-pad en de resolverquery niet.

Vraag de kernel welk pad hij koos

De routingtabel is een voorkeursvolgorde, en het pad dat de kernel kiest is niet altijd dat van het diagram. Vraag het hem rechtstreeks voor de betreffende bestemming. Het antwoord noemt de interface, de volgende hop en het bronadres dat wordt gebruikt. Een pakket kan door de tunnel vertrekken met een bronadres dat de andere kant weigert, en een specifiekere vermelding in de fysieke tabel kan het in plaats daarvan via de Wi-Fi-interface versturen.

ip route get 10.20.30.40
ip -brief address show

Lees de velden dev, via en src in die volgorde, want elk sluit een ander vermoeden uit. Deze fase bezit ook de toestand die de client installeerde, want firewallregels en routes kunnen na een abnormale afsluiting blijven staan. Daarom zijn „geen internet zonder de tunnel“ en „geen internet tenzij de client draait“ één foutenfamilie, niet twee.

Test de pakketgrootte

Een klein antwoord dat terugkomt terwijl een grote overdracht vastloopt, wijst eerst op de MTU van het pad. Eén probe met de do-not-fragment-bit gezet, van binnenuit de tunnel verzonden, scheidt deze fase van de rest. Verhoog de payload tot de probe faalt en je hebt het getal dat ertoe doet.

ping -M do -s 1400 10.20.30.40

Kleine probes die slagen terwijl een mapoverzicht of een upload blijft hangen, is de signatuur van deze fase. De klacht klinkt als inloggegevens of een firewallregel, en het is geen van beide.

Het getal is een eigenschap van het pad, niet van de client, dus een waarde die op een kantoorverbinding werkt, kan op een mobiele verbinding falen. Bewaar het probecommando bij het ticket, want de volgende persoon heeft dezelfde meting nodig. Als een kleinere payload doorkomt, is de oplossing een clamp of een lagere tunnel-MTU, niet een nieuw cijfer.

Test de andere kant

Test de bestemming op zijn adres en kijk dan wat daar luistert. Een geweigerde verbinding en een verbinding die nooit antwoordt, zijn verschillende bevindingen. De eerste zegt dat er iets draait en niet die poort bedient, de tweede dat er niets terugkwam. Geen van beide is standaard een clientprobleem.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Niets dat via een tunnel bereikbaar is, kan een dienst zijn die alleen op 127.0.0.1 luistert, want de listener ziet het pakket nooit. Wanneer de firewall van de verre host het kantoorsubnet toestaat en de tunnelpool weigert, ziet het resultaat eruit als een clientfout en is het er geen. Remote Desktop of bestandsdeling die breekt terwijl webverkeer overleeft, belandt meestal hier, hoe de gebruiker het ook formuleert.

Koppel de klacht aan één fase

De meeste meldingen vallen in een van vijf vormen, en elke vorm noemt een fase. Eén site die alleen via de tunnel werkt, is een naamantwoord of een beleid dat aan het bronadres is gebonden. Updates die zonder de tunnel falen terwijl browsen werkt, is een naam- of routeprobleem voor die client.

Dat alles stopt wanneer een providerclient start, is geïnstalleerde toestand, dus een kwestie van route en firewall. Eén dienst onbereikbaar terwijl de rest in orde is, is de andere kant. Overdrachten die na een paar seconden vastlopen, zijn de pakketgrootte. Koppel de vorm voordat je commando’s uitvoert, want die bepaalt welk bewijs eerst wordt verzameld.

Noteer de fase die de eerste fout opleverde, samen met de uitvoer van het commando. Een ticket dat zegt dat het bronadres fout was, met de routelijn bijgevoegd, is het waard om op te treden, terwijl een dat de VPN als kapot meldt dat niet is.