Hoe u één IPv4-bestemming buiten een OpenVPN-tunnel stuurt

De meeste volledige-tunnelopstellingen sturen elk pakket door de VPN, en redirect-gateway is de richtlijn die dat mogelijk maakt. Eén enkele bestemming kan toch worden uitgezonderd. Een hostroute voor dat adres met de net_gateway-plaatshouder vertelt de client om het via de oorspronkelijke gateway van de machine te bereiken, terwijl al het andere de tunnel blijft gebruiken.

De regel ziet er onschuldig uit en is dat vaak ook, maar hij beslist maar één vraag: waar pakketten voor precies dat IPv4-adres heen gaan. Hij verandert DNS, IPv6, het firewallbeleid of welk proces de verbinding opende niet, en elk daarvan kan de uitzondering stil tenietdoen.

Wat net_gateway eigenlijk benoemt

De profielregel voor die uitzondering is één regel: route 198.51.100.77 255.255.255.255 net_gateway. Het eerste adres is een documentatie-plaatshouder voor de bestemming, het masker maakt er een hostroute van één host van, en het laatste token benoemt de gateway-plaatshouder. OpenVPN lost gateway-plaatshouders op wanneer het routes installeert. vpn_gateway betekent de eigen gateway van de tunnel, de verre kant van de VPN-verbinding. net_gateway betekent de standaardgateway die de host had voordat de VPN iets veranderde, meestal de lokale router op het fysieke netwerk.

Een derde plaatshouder, remote_host, verwijst naar het adres van de VPN-server, en hij bestaat zodat de tunnel de server via het fysieke pad kan bereiken. Deze drie door elkaar halen is de meest voorkomende reden dat een uitzondering op de verkeerde plek belandt of helemaal niet wordt geïnstalleerd.

De waarde wordt bij het verbinden gelezen, niet in het bestand geschreven. Als de machine naar een ander netwerk gaat, verandert de gateway van vóór de VPN en de route volgt de nieuwe. Dat is meestal wat u wilt, maar het betekent ook dat het gedrag van de uitzondering afhangt van het netwerk waarvan de client is gestart.

Waarom een hostroute de standaardroute van de tunnel verslaat

Routing wordt bepaald door het meest specifieke overeenkomende prefix. redirect-gateway def1 vervangt normaal gesproken niet de standaardroute; het voegt twee helften toe, een route voor de onderste helft van de adresruimte en een voor de bovenste, zodat de oorspronkelijke standaardroute voor ander gebruik bewaard blijft. Die helften zijn breder dan één adres.

Een route voor één adres met masker 255.255.255.255 is een /32, wat zo specifiek is als IPv4 kan worden. Wanneer een pakket voor dat adres wordt beoordeeld, past de /32 en wint, ongeacht welke route het eerst werd geïnstalleerd. Dat is het mechanisme achter de uitzondering, en het werkt hetzelfde op Linux, macOS en Windows zolang de route er echt is.

Windows voegt een tweede dimensie toe. Wanneer twee routes even specifiek zijn, wint degene met de lagere metriek, en een VPN-adapter kan een interfacemetriek dragen die de uitkomst verandert. Een /32 blijft specifieker dan de helften, dus de uitzondering houdt meestal stand, maar een verouderde route uit een eerdere sessie kan een verwarrend resultaat geven als die even specifiek is.

Wat de uitzondering niet dekt

DNS is de eerste opening. De client kan interne resolverinstellingen doorduwen, en het besturingssysteem blijft ze gebruiken voor opzoekingen. Een toepassing die een naam oplost voordat ze verbindt, kan een intern adres krijgen voor een dienst die rechtstreeks hoort te gaan, of een extern adres dat correct wordt opgelost maar daarna over de volgende opening struikelt.

IPv6 is de tweede. De routerichtlijn behandelt alleen IPv4. Een dual-stackbestemming kan IPv6 verkiezen, dat afhankelijk van het beleid de tunnel of de IPv6-standaardroute van de host volgt, zodat de IPv4-uitzondering nooit in werking treedt. U hebt een overeenkomende IPv6-route nodig, of een bewuste beslissing om IPv6 voor die client uit te schakelen.

Het toepassingsbereik is de derde. De regel is op de bestemming gebaseerd, dus elk proces dat met dat adres verbindt, gebruikt het directe pad, of het nu het proces is dat u in gedachten had of niet. Omgekeerd kan een website vanaf meerdere adressen antwoorden, dus één /32 uitzonderen zondert de site niet uit. Als de echte eis routering per toepassing is, is de routetabel van de Community-client het verkeerde gereedschap.

De uitzondering controleren zonder uzelf te bedriegen

Begin met de geïnstalleerde route, niet met een browser. Vraag op Linux aan de kernel welke route en volgende hop hij voor het specifieke adres gebruikt; lees op Windows de routetabel voor die /32. Bevestig dat de gateway de fysieke is en niet de tunnel. Als de vermelding ontbreekt, is het profiel niet toegepast of had de client niet het recht om routes te wijzigen.

Test daarna twee bestemmingen. Een verzoek naar het uitgezonderde adres hoort via de fysieke interface naar buiten te gaan, en een verzoek naar een intern controleadres hoort nog steeds de tunnel te gebruiken. Alleen het uitgezonderde adres testen bewijst niets over de rest van de tunnel, en een openbare website testen test het adres waarnaar die site is opgelost, dat misschien niet het adres uit de regel is.

Controleer ten slotte de bedieningselementen die de route kunnen overrulen. Een kill switch aan de clientzijde of een Windows-instelling block-outside-dns kan direct verkeer verbieden, wat zich toont als een verbinding die faalt terwijl de route correct is. Schakel die bedieningselementen niet uit om de uitzondering te laten lijken werken; als het beleid het directe pad verbiedt, is de uitzondering een ontwerpprobleem voor de eigenaar van de VPN-dienst.

Controleer opnieuw na opnieuw verbinden of netwerkwissel, want de gateway van vóór de VPN en het beschikbare pad zijn eigenschappen van het moment, niet van het profiel.