Så skickar du en enda IPv4-destination utanför en OpenVPN-tunnel

De flesta fulltunnelkonfigurationer skickar varje paket genom VPN, och redirect-gateway är direktivet som gör det möjligt. En enda destination kan ändå undantas. Att lägga till en värdrutt för den adressen med net_gateway-platshållaren säger åt klienten att nå den via maskinens ursprungliga gateway, medan allt annat fortsätter att använda tunneln.

Raden ser oskyldig ut och är det ofta, men den avgör bara en fråga: vart paketen till just den IPv4-adressen tar vägen. Den ändrar inte DNS, IPv6, brandväggspolicyn eller vilken process som öppnade anslutningen, och var och en av dessa kan tyst göra undantaget verkningslöst.

Vad net_gateway egentligen namnger

Profilposten för det undantaget är en rad: route 198.51.100.77 255.255.255.255 net_gateway. Den första adressen är en dokumentationsplatshållare för destinationen, masken gör den till en värdrutt för en enda värd, och den sista token namnger gateway-platshållaren. OpenVPN löser gateway-platshållare när den installerar rutter. vpn_gateway betyder tunnelns egen gateway, den bortre sidan av VPN-länken. net_gateway betyder den standardgateway som värden hade innan VPN ändrade något, vilket vanligtvis är den lokala routern i det fysiska nätet.

En tredje platshållare, remote_host, syftar på VPN-serverns adress, och den finns för att tunneln ska kunna nå servern via den fysiska vägen. Att blanda ihop dessa tre är den vanligaste orsaken till att ett undantag hamnar på fel ställe eller inte installeras alls.

Värdet läses vid anslutning, skrivs inte in i filen. Om maskinen flyttas till ett annat nät ändras gatewayen före VPN, och rutten följer den nya. Det är vanligtvis vad du vill, men det betyder också att undantagets beteende beror på nätet som klienten startade från.

Varför en värdrutt vinner över tunnelns standardrutt

Routning avgörs av det mest specifika matchande prefixet. redirect-gateway def1 ersätter vanligtvis inte standardrutten; den lägger till två halvor, en rutt för den nedre halvan av adressutrymmet och en för den övre, så att den ursprungliga standardrutten bevaras för annat bruk. Dessa halvor är bredare än en enda adress.

En rutt för en adress med masken 255.255.255.255 är en /32, vilket är så specifikt som IPv4 kan bli. När ett paket till den adressen utvärderas matchar /32 och vinner oavsett vilken rutt som installerades först. Det är mekanismen bakom undantaget, och den fungerar likadant på Linux, macOS och Windows så länge rutten faktiskt finns.

Windows lägger till en andra dimension. När två rutter är lika specifika vinner den med lägre metrik, och en VPN-adapter kan bära ett gränssnittsmetrik som ändrar resultatet. En /32 är fortfarande mer specifik än halvorna, så undantaget håller vanligtvis, men en inaktuell rutt från en tidigare session kan ge ett förvirrande resultat om den är lika specifik.

Vad undantaget inte täcker

DNS är den första luckan. Klienten kan trycka in interna resolverinställningar, och operativsystemet fortsätter att använda dem för uppslag. Ett program som löser ett namn innan det ansluter kan få en intern adress för en tjänst som borde gå direkt, eller en extern adress som löses korrekt men sedan snubblar på nästa lucka.

IPv6 är den andra. Ruttdirektivet hanterar bara IPv4. En destination med dubbel stack kan föredra IPv6, som följer tunneln eller värdens IPv6-standardrutt beroende på policy, så IPv4-undantaget träder aldrig i kraft. Du behöver en matchande IPv6-rutt, eller ett medvetet beslut att inaktivera IPv6 för den klienten.

Programomfattningen är den tredje. Regeln är destinationsbaserad, så varje process som ansluter till den adressen använder den direkta vägen, oavsett om det är den du tänkte på. Omvänt kan en webbplats svara från flera adresser, så ett undantag för en /32 undantar inte webbplatsen. Om det egentliga kravet är routning per program, är Community-klientens rutttabell fel verktyg.

Kontrollera undantaget utan att lura dig själv

Börja med den installerade rutten, inte med en webbläsare. På Linux, fråga kärnan vilken rutt och nästa hopp den använder för den specifika adressen; på Windows, läs rutttabellen för den /32. Bekräfta att gatewayen är den fysiska och inte tunneln. Om posten saknas tillämpades inte profilen, eller klienten hade inte behörighet att ändra rutter.

Testa sedan två destinationer. En begäran till den undantagna adressen bör gå ut via det fysiska gränssnittet, och en begäran till en intern kontrolladress bör fortfarande använda tunneln. Att bara testa den undantagna adressen bevisar ingenting om resten av tunneln, och att testa en offentlig webbplats testar den adress som webbplatsen löstes till, vilken kanske inte är den i regeln.

Kontrollera slutligen de kontroller som kan åsidosätta rutten. En kill switch på klientsidan eller en Windows-inställning block-outside-dns kan förbjuda direkt trafik, vilket visar sig som en anslutning som misslyckas trots att rutten är korrekt. Inaktivera inte dessa kontroller för att få undantaget att se ut som det fungerar; om policyn förbjuder den direkta vägen är undantaget ett designproblem för den som äger VPN-tjänsten.

Kontrollera igen efter återanslutning eller nätverksbyte, eftersom gatewayen före VPN och den tillgängliga vägen är egenskaper hos ögonblicket, inte hos profilen.