Volledige tunnel of endpointroute: de VPN-server bereikbaar houden

Voeg een standaardroute via de tunnel toe, en de pakketten van de tunnel zelf volgen die. De tabel bevat dan een regel die zichzelf verslaat. De versleutelde verbinding met de server probeert binnen de verbinding te reizen die hij probeert op te zetten.

Twee mechanismen voorkomen die lus. Het ene is zichtbaar in de routetabel, het andere leeft in de applicatie.

Intern en extern verkeer zijn verschillende beslissingen

Een applicatiepakket komt de virtuele interface binnen en wordt ingekapseld. Het resultaat is een nieuw pakket dat aan het openbare adres van de server is geadresseerd. Dat pakket heeft een route op het fysieke netwerk nodig, want niets ervan mag de tunnel in.

Beide zijn routeringsbeslissingen, en alleen de eerste hoort bij de tunnel. Wanneer de client een standaardroute installeert die ook de server dekt, wordt het buitenste pakket ook gevangen.

De symptomen zijn onmiddellijk en totaal. De handshake rondt af en daarna stroomt er niets meer, of de verbinding valt op het moment dat de route wordt geïnstalleerd. In beide gevallen kan de keepalive er niet meer uit.

Optie één: een hostroute voor het endpoint

De directe aanpak voegt een route toe voor het adres van de server via de oorspronkelijke gateway. Het kost één regel. Het is zichtbaar voor iedereen die de tabel leest. Het is ook makkelijk uit te leggen in een wijzigingsrecord.

De zwakte ervan komt naar voren wanneer het onderliggende pad verandert. De opgeslagen route noemt een gateway en een interface uit het oude netwerk. Na een Wi-Fi-wissel bestaat die gateway misschien niet meer, en de route blijft achter, ziet er correct uit en doet niets.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Een hostnaam maakt dit lastiger. Als het endpoint een naam is die naar meerdere adressen oplost, moet de uitzondering het adres dekken dat daadwerkelijk in gebruik is. Een latere opzoeking kan iets teruggeven dat de route nooit heeft gedekt.

Optie twee: de socket beschermen

De andere aanpak raakt de routetabel nooit aan. De client markeert of beschermt de socket die de tunnel draagt, zodat het besturingssysteem het verkeer van die socket volgens beleid buiten de tunnel stuurt. Android stelt het mechanisme rechtstreeks beschikbaar aan VPN-applicaties. Desktopclients implementeren equivalenten met firewallmarkeringen of bind-aan-apparaat-aanroepen.

Het voordeel is dat de uitzondering de verbinding volgt in plaats van een opgeslagen gateway. Een netwerkwijziging herschrijft het onderliggende pad, en de beschermde socket beweegt mee omdat hij nooit aan een adres was vastgezet. De routetabel blijft schoon.

De prijs is zichtbaarheid. Niets in de routetabel toont de uitzondering, dus een beoordelaar die naar een hostroute zoekt vindt niets en kan concluderen dat het ontwerp onveilig is. De bescherming leeft in de code van de client en in de beleidsregels die deze code installeert.

Kiezen tussen beide

Kies het socketmechanisme wanneer de client het ondersteunt, want het overleeft de netwerkwijzigingen die een vastgezette route breken. Kies de hostroute wanneer de uitzondering zichtbaar moet zijn voor andere hulpmiddelen, of wanneer de client niets beters biedt.

Geen van beide mechanismen neemt de noodzaak weg dat het adres van de server überhaupt bereikbaar is. Een privégateway heeft een openbaar luisteradres, en dat is het adres dat buiten de tunnel moet blijven. De interne netwerken erachter worden pas bereikbaar als de tunnel bestaat.

Wat u ook kiest, houd het bij het onderdeel dat de tunnel bezit. Een losse hostroute die met de hand is toegevoegd werkt tot het volgende netwerk, en dan wordt het de mysterieuze storing van morgen.