OpenVPN redirect-gateway: wat elke vlag met de routes doet

Verbind met redirect-gateway in het profiel, en de standaardroute van je machine kan verdwijnen, in tweeën splitsen of precies blijven waar hij was, afhankelijk van vlaggen die niemand twee keer leest. De optie wijzigt alleen de routingstatus en niets anders, dus het enige betrouwbare bewijs van wat hij deed is de tabel die de client daarna installeerde. Wat volgt is de tabel na een verbinding, de route die de tunnel zelf in leven houdt, en het IPv6-verkeer dat de richtlijn nooit claimt te dekken. Elke stap is een commando dat je op de client kunt uitvoeren terwijl de tunnel actief is.

Wat elke vlag met de standaardroute doet

Zonder enige vlag verwijdert de optie de gewone standaardroute en zet de tunnel in zijn plaats, zodat de oude gateway uit de tabel verdwijnt zolang de verbinding actief is. Voeg def1 toe en die standaard blijft vermeld, met twee smallere routes die het werk doen. Voeg bypass-dhcp toe en de DHCP-route overleeft ook, wat telt op een netwerk waar de client nog de lokale DHCP-server moet bereiken. De vlaggenlijst op de handleidingspagina van OpenVPN 2.6 is kort genoeg om één keer te lezen, en elke vermelding verandert welke routes in de tabel belanden.

Een gepushte optie gedraagt zich hetzelfde zodra hij aankomt, dus het clientprofiel kan niets bevatten terwijl de tabel volledig omgeleid lijkt. Dat is normaal: de server stuurde de vlaggen, de client paste ze toe, en het lokale bestand noemde de richtlijn nooit. Wanneer een push niets lijkt te doen, controleer het filter aan de clientzijde dat opgehaalde opties accepteert of weggooit, want een weggegooide optie geeft aan geen van beide kanten een fout.

def1 wint op specificiteit zonder je standaard aan te raken

Twee half-standaardroutes dekken samen de IPv4-ruimte, 0.0.0.0/1 en 128.0.0.0/1. Elk is specifieker dan 0.0.0.0/0, dus een opzoeking verkiest ze terwijl de echte standaard in de tabel blijft voor alles wat de minst specifieke match vraagt.

Lees de tabel in plaats van het profiel, want alleen de tabel toont in welk van die gevallen je zit. Twee regels volstaan om ze te onderscheiden:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Let op de interface en de metriek op elke regel, niet alleen op de bestemming. Een standaard die naar de tunnel wijst en een paar half-standaarden die naar de tunnel wijzen beschrijven dezelfde bedoeling en falen anders wanneer de tunnel wegvalt, omdat de terugval in één geval nog bestaat. Noteer beide velden in de wijzigingsnotitie. Een overlevende terugval is soms wat een externe sessie lang genoeg in leven houdt om de tunnel te herstellen, en het is ook wat verkeer lekt wanneer de bedoeling een volledige tunnel was.

Houd het eindpunt van de tunnel bereikbaar

De client heeft een route nodig naar het verre uiteinde van de tunnel die zelf niet door de tunnel loopt. OpenVPN installeert die hostroute voordat het iets anders wijzigt, en een handmatige routewijziging of een tweede VPN-client kan hem wegnemen. Het symptoom daarna is een verbinding die meldt dat hij verbonden is en dan niets doorlaat.

Vraag de kernel welke interface hij zou gebruiken voor het eindpuntadres terwijl de tunnel actief is. Het antwoord moet de fysieke interface en zijn gateway noemen, nooit tun0:

ip route get 198.51.100.20

Als die opzoeking het tunnelapparaat teruggeeft, draagt de tunnel zijn eigen transport en stort hij in zodra een pakket naar buiten moet. Lokale prefixen, een tweede adapter en policy-routing tellen hier nog steeds, daarom kan een omleiding die op een schone laptop werkt falen op een host met een beheerinterface en twee standaardroutes. Meestal krijgt het profiel de schuld van wat het adresplan deed.

IPv6-verkeer blijft zijn eigen tabel gebruiken

IPv4 omleiden laat IPv6 met rust, en de twee families worden door verschillende vlaggen gewijzigd. Op een dual-stack-host met een werkende v6-standaard kan v4-verkeer volledig in de tunnel zitten terwijl elke v6-capabele bestemming via de fysieke link naar buiten gaat. Een host die er in de ene tabel goed uitziet, lekt in de andere.

Controleer de v6-tabel na het verbinden in plaats van aan te nemen dat de tunnel hem dekte. De richtlijn draagt adresfamilievlaggen precies daarom, en een profiel dat ze weglaat erft wat het platform standaard doet:

ip -6 route show default
ip -6 route get 2001:db8::10

Bewijs welke interface een toepassing gebruikt

Een verbonden status is geen blokkade, en een routewijziging is geen kill switch. Als direct verkeer moet stoppen wanneer de tunnel faalt, leeft dat beleid in de firewall en heeft het zijn eigen test nodig.

Test het pad dat een toepassing werkelijk volgt in plaats van het pad dat het profiel beschrijft. Vraag eerst de route op, bind dan om beurten een verzoek aan elke interface en vergelijk wat de andere kant meldt:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Als beide verzoeken hetzelfde adres teruggeven, gebruikt de toepassing de tunnel niet terwijl de routingtabel zegt dat het zou moeten. Als alleen het aan de tunnel gebonden verzoek slaagt, is het fysieke pad voor die bestemming gefilterd en doet de tunnel wat je vroeg. Schrijf de vlaggen, de geïnstalleerde routes, de eindpuntopzoeking en beide uitgangsresultaten in het wijzigingsrecord, zodat de volgende persoon feiten erft in plaats van een schermafbeelding.