Slik sender du én IPv4-destinasjon utenom en OpenVPN-tunnel

De fleste fulltunnel-oppsett sender hver pakke gjennom VPN-en, og redirect-gateway er direktivet som gjør det mulig. Én enkelt destinasjon kan likevel unntas. Å legge til en vertsrute for den adressen med net_gateway-plassholderen forteller klienten å nå den gjennom maskinens opprinnelige gateway, mens alt annet fortsatt bruker tunnelen.

Linjen ser harmløs ut og er ofte det, men den avgjør bare ett spørsmål: hvor pakkene til nøyaktig den IPv4-adressen går. Den endrer ikke DNS, IPv6, brannmurpolicyen eller hvilken prosess som åpnet forbindelsen, og hver av disse kan stille gjøre unntaket virkningsløst.

Hva net_gateway egentlig navngir

Profiloppføringen for det unntaket er én linje: route 198.51.100.77 255.255.255.255 net_gateway. Den første adressen er en dokumentasjonsplassholder for destinasjonen, masken gjør den til en enkeltvertsrute, og det siste tokenet navngir gateway-plassholderen. OpenVPN løser gateway-plassholdere når den installerer ruter. vpn_gateway betyr tunnelens egen gateway, den fjerne siden av VPN-forbindelsen. net_gateway betyr standardgatewayen verten hadde før VPN-en endret noe, som vanligvis er den lokale ruteren på det fysiske nettet.

En tredje plassholder, remote_host, viser til VPN-serverens adresse, og den finnes for at tunnelen skal kunne nå serveren over den fysiske veien. Å blande disse tre er den vanligste årsaken til at et unntak havner på feil sted eller ikke installeres i det hele tatt.

Verdien leses ved tilkobling, ikke skrevet inn i filen. Hvis maskinen flyttes til et annet nett, endres gatewayen før VPN-en, og ruten følger den nye. Det er vanligvis det du vil, men det betyr også at unntakets oppførsel avhenger av nettet klienten startet fra.

Hvorfor en vertsrute vinner over tunnelens standardrute

Ruting avgjøres av det mest spesifikke samsvarende prefikset. redirect-gateway def1 erstatter vanligvis ikke standardruten; den legger til to halvdeler, en rute for den nedre halvdelen av adresseområdet og en for den øvre, slik at den opprinnelige standardruten bevares for annet bruk. Disse halvdelene er bredere enn én adresse.

En rute for én adresse med maske 255.255.255.255 er en /32, som er så spesifikt som IPv4 kan bli. Når en pakke til den adressen vurderes, samsvarer /32 og vinner uansett hvilken rute som ble installert først. Det er mekanismen bak unntaket, og den virker likt på Linux, macOS og Windows så lenge ruten faktisk finnes.

Windows legger til en andre dimensjon. Når to ruter er like spesifikke, vinner den med lavest metrikk, og en VPN-adapter kan ha en grensesnittmetrikk som endrer resultatet. En /32 er fortsatt mer spesifikk enn halvdelene, så unntaket holder vanligvis, men en utdatert rute fra en tidligere økt kan gi et forvirrende resultat hvis den er like spesifikk.

Hva unntaket ikke dekker

DNS er det første gapet. Klienten kan dytte interne resolverinnstillinger, og operativsystemet vil fortsette å bruke dem til oppslag. En applikasjon som løser et navn før den kobler til, kan få en intern adresse for en tjeneste som skal gå direkte, eller en ekstern adresse som løses riktig, men deretter snubler over det neste gapet.

IPv6 er den andre. Rutedirektivet håndterer bare IPv4. En destinasjon med dobbelt stakk kan foretrekke IPv6, som følger tunnelen eller vertens IPv6-standardrute avhengig av policy, slik at IPv4-unntaket aldri trer i kraft. Du trenger en samsvarende IPv6-rute, eller en bevisst beslutning om å deaktivere IPv6 for den klienten.

Applikasjonsomfanget er det tredje. Regelen er destinasjonsbasert, så enhver prosess som kobler til den adressen, bruker den direkte veien, enten det er den du hadde i tankene eller ikke. Omvendt kan et nettsted svare fra flere adresser, så et unntak for én /32 unntar ikke nettstedet. Hvis det egentlige kravet er ruting per applikasjon, er rutetabellen til Community-klienten feil verktøy.

Kontroller unntaket uten å lure deg selv

Begynn med den installerte ruten, ikke med en nettleser. På Linux, spør kjernen hvilken rute og neste hopp den vil bruke for den konkrete adressen; på Windows, les rutetabellen for den /32-en. Bekreft at gatewayen er den fysiske og ikke tunnelen. Hvis oppføringen mangler, ble profilen ikke brukt, eller klienten hadde ikke rettighet til å endre ruter.

Test deretter to destinasjoner. En forespørsel til den unntatte adressen skal gå ut gjennom det fysiske grensesnittet, og en forespørsel til en intern kontrolladresse skal fortsatt bruke tunnelen. Å teste bare den unntatte adressen beviser ingenting om resten av tunnelen, og å teste et offentlig nettsted tester adressen det nettstedet ble løst til, som kanskje ikke er den i regelen.

Til slutt, kontroller styringene som kan overstyre ruten. En kill switch på klientsiden eller en Windows-innstilling block-outside-dns kan forby direkte trafikk, noe som vises som en forbindelse som feiler selv om ruten er riktig. Ikke deaktiver disse styringene for å få unntaket til å se ut som det virker; hvis policyen forbyr den direkte veien, er unntaket et designproblem for den som eier VPN-tjenesten.

Kontroller på nytt etter gjentilkobling eller nettverksbytte, fordi gatewayen før VPN-en og den tilgjengelige veien er egenskaper ved øyeblikket, ikke ved profilen.