Start je een VPN-client via SSH? Leg eerst je eigen route vast

Je logt via SSH in op een build-host, start daar de VPN-client, en de sessie antwoordt niet meer. Niets is gecrasht, en niets ziet er op het eerste gezicht verkeerd geconfigureerd uit. De client installeerde een standaardroute, dus antwoorden naar je werkstation verlaten nu de tunnel, waar het adres van je werkstation niet routeerbaar is. Het interessante is dat deze uitkomst voorspelbaar was, en de oplossing is één route die vóór de start van de client wordt geschreven. Stel een server met één netwerkkaart voor, een gateway van 192.0.2.254, en een beheerder die vanaf 203.0.113.9 verbindt.

Noteer het pad voordat je begint

ip route show default noemt de huidige gateway en interface, terwijl ip route get 203.0.113.9 laat zien welke interface en welk bronadres de kernel voor je sessie zou gebruiken. Bewaar beide uitvoer. Nadat de tunnel omhoog komt, zouden die twee commando's nog steeds het fysieke pad moeten beschrijven, en als ze in plaats daarvan de tunnel beschrijven, leeft de sessie al op geleende tijd.

Het gaat om de al opgezette verbinding, dus valideer niet alleen met een nieuwe login. Een nieuwe sessie kan kort lukken dankzij toestand die de oude niet meer heeft.

Leg het adres vast in de configuratie van de client zelf

Een handmatig toegevoegde route verdwijnt bij een herstart en racet met de eigen tabelupdates van de client, dus zet de uitzondering waar de tabel wordt beheerd. Onder OpenVPN lost het sleutelwoord net_gateway op naar de gateway die vóór de tunnel bestond, dus route 203.0.113.9 255.255.255.255 net_gateway houdt precies één adres erbuiten. WireGuard vereist een andere aanpak omdat wg-quick de routes zelf beheert: stel Table = off in en voeg de uitzondering toe in PostUp, met een bijpassende PostDown die hem verwijdert. Beide vormen drukken dezelfde bedoeling uit, en beide beperken de uitzondering tot één adres in plaats van de tunnel voor alles te verzwakken.

Voor IPv6 neemt hetzelfde idee een enkelhost-prefix, en het geval van ingepakt transport is het onthouden waard: als de buitenste verbinding van de tunnel zelf op een vast adres leeft, moet dat adres buiten de tunnel blijven die het draagt, anders routeert de client zijn eigen transport naar zichzelf.

Of haal de hoofdtabel uit de vergelijking

Wanneer meerdere diensten op de host hun normale pad moeten houden, stop dan met het bewerken van de hoofdtabel en geef de client zijn eigen tabel. Een netwerknaamruimte met een veth-paar doet dat netjes: de standaardroute van de client leeft in een andere stack en alleen processen die daarbinnen starten gebruiken de tunnel. Policy routing bereikt een vergelijkbare plek voor één bestemming, door overeenkomend verkeer naar een toegewijde tabel te sturen waarvan de standaard nog naar de fysieke gateway wijst. Beide benaderingen laten de hoofdtabel van de host zonder nieuwe standaardroute, en dat is de eigenschap die SSH blijft laten antwoorden.

Beide zijn meer machinerie dan één hostroute, en beide zijn het waard als meer dan één ding op de machine de tunnel moet overleven.

Ga ervan uit dat het vastleggen kan mislukken

Een route die aan je huidige openbare adres is gekoppeld, breekt op het moment dat je provider het opnieuw toewijst. Een externe server heeft dan een pad nodig dat niet van dat adres afhangt: een console, een tweede beheerinterface of een jumphost die buiten de tunnel blijft.

Twee voorzorgsmaatregelen kosten tien minuten. Een watchdog die de client stopt als er binnen enkele minuten geen bevestigingslogin verschijnt, verandert een uitsluiting in een vertraging, en een tweede SSH-sessie die tijdens de wijziging open blijft, bewijst dat de uitzondering werkt terwijl de tunnel omhoog is. Alleen keepalives helpen hier niet, omdat het pad weg is in plaats van inactief; ze maken de dood alleen makkelijker te merken.

Verifieer in de volgorde die ertoe doet

Verbind de tunnel, bevestig dat de route naar je adres nog via de fysieke gateway verlaat, en open dan een nieuwe sessie. Als de nieuwe sessie werkt en de oude toch sterft, is de oorzaak connection tracking of een stateful firewall en niet routing, wat een andere oplossing is.

Schrijf het vastgelegde adres en het commando dat het bewees in het wijzigingslogboek. De volgende persoon die op die host een client start, heeft beide nodig, en het adres kan tegen die tijd veranderd zijn.