Je oude standaardroute overleeft OpenVPN bewust

Je verbindt de tunnel, voert ip route uit, en de oorspronkelijke standaardgateway staat er nog steeds. De volgende gedachte is dat de client de route niet heeft overgenomen, dus je verwijdert de standaard handmatig en verliest de verbinding volledig. Die vermelding hoort te blijven staan. Met redirect-gateway def1 installeert OpenVPN twee specifiekere routes die de gewone standaard overtreffen in plaats van hem te vervangen. De oude gateway blijft staan en vervoert het verkeer dat je testte niet meer.

Wat def1 echt doet

De vlag voegt 0.0.0.0/1 en 128.0.0.0/1 toe, beide naar de tunnel wijzend. 0.0.0.0/1 dekt elk adres waarvan het eerste octet 0 tot 127 is, en 128.0.0.0/1 dekt 128 tot 255, dus elke IPv4-bestemming heeft een specifiekere match dan de oude standaardroute. De prefixlengte, niet de metriek, bepaalt welke route wint.

De oorspronkelijke standaard laten staan is bewust. De client hoeft niet te onthouden wat hij verving, en hij herschrijft de route niet die zijn eigen verbinding met de VPN-server draagt. Bij het verbreken verwijdert hij de twee halve routes en de tabel keert terug naar wat hij was.

Waarom /1 en niet /0

Routing kiest de langste overeenkomende prefix, niet de laagste metriek, dus een /1 verslaat een /0 wat de metriek van de standaard ook zegt. Beide helften bestaan omdat één /1 maar de helft van de ruimte dekt; met alleen 0.0.0.0/1 volgt alles vanaf 128.0.0.0 nog steeds de oude standaard, wat het verwarrende symptoom geeft dat sommige sites werken en andere niet.

De metriek van de oude standaard verhogen of verlagen verandert niets, en een standaard met een lagere metriek op een andere interface steelt het verkeer ook niet. Eerst beslist de prefixlengte, en alleen gelijke prefixes vallen terug op de metriek.

Lees een echte routingtabel

Een verbonden host kan alle drie de vermeldingen tegelijk tonen, waarbij de tunnel de helften draagt en de oorspronkelijke gateway nog in de lijst staat. De adressen zijn voorbeelden en geen configuratie om te kopiëren, omdat interfacenamen, tunneltopologie en extra routes per platform en client verschillen.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Wat telt is de verhouding: twee specifieke helften boven één algemene standaard. De regel van de oude gateway blijft omdat niets hem heeft vervangen.

Controleer welke route het pakket echt neemt

Specifiekere routes kunnen nog steeds winnen: een route voor een privébereik, een lokaal subnet of het eigen adres van de VPN-server is langer dan een /1. De tunnel heeft een buitenste pad naar zijn server nodig, en die verbinding terug de tunnel in sturen zou hem meteen breken. Vraag op Linux de kernel in plaats van de tabel met het oog te lezen: ip route get met de bestemming die je interesseert print de gekozen route, interface en bron. Is er policy-routing geconfigureerd, bekijk dan ook de regels, want een regel kan een andere tabel kiezen voordat de hoofdtabel wordt geraadpleegd.

Als slechts een deel van IPv4 zich verkeerd gedraagt, bevestig dan dat beide helften zijn geïnstalleerd en zoek daarna naar een uitzondering die bij de falende bestemming past. De oude standaard verwijderen is geen oplossing, en het haalt de route weg die de client nodig heeft om de tunnel schoon af te breken.

Wat def1 niet dekt

Twee IPv4-vermeldingen zeggen niets over IPv6: een host met IPv6-connectiviteit blijft zijn eigen standaard gebruiken tot iets die familie apart omleidt, waardoor op een dual-stacknetwerk een deel van het verkeer de tunnel lijkt te omzeilen. Andere clients en netwerkbeheerders implementeren full-tunnel-routing anders, en hun tabellen zullen niet overeenkomen. Het hier beschreven def1-gedrag hoort bij de gedocumenteerde vlag van OpenVPN, niet bij elke VPN op de machine.

Een killswitch beantwoordt een andere vraag: wat de machine doet als de tunnel wegvalt. Routeprioriteit bepaalt waar het verkeer heen gaat zolang de tunnel actief is; het bepaalt niet wat een firewall daarna doet. Werkvolgorde: lees de tabel, bevestig dat beide helften bestaan, voer ip route get uit voor de falende bestemming, controleer de policyregels en kijk daarna apart naar IPv6. Laat de oude standaard staan waar hij is.