Din gamle standardrute overlever OpenVPN med vilje

Du opretter tunnelen, kører ip route, og den oprindelige standardgateway står stadig der. Den næste tanke er, at klienten ikke har overtaget ruten, så du sletter standardruten manuelt og mister forbindelsen helt. Den post skal blive stående. Med redirect-gateway def1 installerer OpenVPN to mere specifikke ruter, som overgår den almindelige standardrute i stedet for at erstatte den. Den gamle gateway bliver og holder op med at bære den trafik, du testede.

Hvad def1 faktisk gør

Flaget tilføjer 0.0.0.0/1 og 128.0.0.0/1, begge pegende mod tunnelen. 0.0.0.0/1 dækker hver adresse, hvis første oktet er 0 til 127, og 128.0.0.0/1 dækker 128 til 255, så enhver IPv4-destination har et match, der er mere specifikt end den gamle standardrute. Det er præfiksets længde, ikke metrikken, der afgør, hvilken rute der vinder.

At lade den oprindelige standardrute blive er bevidst. Klienten skal ikke huske, hvad den erstattede, og den omskriver ikke den rute, der bærer dens egen forbindelse til VPN-serveren. Ved afbrydelse fjerner den de to halve ruter, og tabellen vender tilbage til det, den var.

Hvorfor /1 og ikke /0

Routing vælger det længste matchende præfiks, ikke den laveste metrik, så en /1 slår en /0, uanset hvad standardrutens metrik siger. Begge halvdele findes, fordi en /1 kun dækker halvdelen af rummet; med kun 0.0.0.0/1 til stede følger alt fra 128.0.0.0 og opefter stadig den gamle standardrute, hvilket giver det forvirrende symptom, at nogle websteder virker og andre ikke.

At hæve eller sænke den gamle standardrutes metrik ændrer intet, og en standardrute med lavere metrik på en anden grænseflade stjæler heller ikke trafikken. Præfiksets længde afgør først, og kun ens præfikser falder tilbage til metrikken.

Læs en rigtig routingtabel

En tilsluttet vært kan vise alle tre poster på én gang, med tunnelen der bærer halvdelene, og den oprindelige gateway stadig på listen. Adresserne er eksempler og ikke en konfiguration, der skal kopieres, fordi grænsefladenavne, tunneltopologi og ekstra ruter varierer efter platform og klient.

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

Det vigtige er forholdet: to bestemte halvdele over én generel standardrute. Linjen med den gamle gateway bliver, fordi intet erstattede den.

Se hvilken rute pakken reelt tager

Mere specifikke ruter kan stadig vinde: en rute til et privat område, et lokalt subnet eller VPN-serverens egen adresse er længere end en /1. Tunnelen har brug for en ydre vej til sin server, og at sende den forbindelse tilbage i tunnelen ville ødelægge den med det samme. På Linux spørg kernen i stedet for at læse tabellen med øjet: ip route get med den destination, du interesserer dig for, udskriver den valgte rute, grænseflade og kilde. Hvis der er konfigureret policy routing, så undersøg også reglerne, fordi en regel kan vælge en anden tabel, før hovedtabellen konsulteres.

Hvis kun en del af IPv4 opfører sig forkert, så bekræft, at begge halvdele er installeret, og se derefter efter en undtagelse, der matcher den fejlende destination. At slette den gamle standardrute er ikke en løsning, og det fjerner den rute, klienten har brug for til at rive tunnelen rent ned.

Hvad def1 ikke dækker

To IPv4-poster siger intet om IPv6: en vært med IPv6-forbindelse bliver ved med at bruge sin egen standardrute, indtil noget omdirigerer den familie separat, og derfor ser noget trafik ud til at omgå tunnelen på et dual-stack-netværk. Andre klienter og netværksadministratorer implementerer full-tunnel routing anderledes, og deres tabeller vil ikke stemme overens. Den def1-adfærd, der beskrives her, hører til OpenVPNs dokumenterede flag, ikke til enhver VPN på maskinen.

En kill switch besvarer et andet spørgsmål: hvad maskinen gør, når tunnelen falder. Ruteprioritet afgør, hvor trafikken går, mens tunnelen er oppe; det afgør ikke, hvad en firewall gør bagefter. Arbejdsrækkefølge: læs tabellen, bekræft at begge halvdele findes, kør ip route get for den fejlende destination, tjek policyreglerne, og se så på IPv6 separat. Lad den gamle standardrute blive, hvor den er.