Sådan sender du én IPv4-destination uden om en OpenVPN-tunnel

De fleste opsætninger med fuld tunnel sender hver pakke gennem VPN'en, og redirect-gateway er det direktiv, der gør det muligt. En enkelt destination kan stadig undtages. Hvis man tilføjer en værtsrute for den adresse med net_gateway-pladsholderen, får klienten besked om at nå den gennem maskinens oprindelige gateway, mens alt andet fortsat bruger tunnelen.

Linjen ser uskyldig ud og er det ofte, men den afgør kun ét spørgsmål: hvor pakker til netop den IPv4-adresse går hen. Den ændrer ikke DNS, IPv6, firewallpolitik eller hvilken proces der åbnede forbindelsen, og hver af disse kan stille og roligt undergrave undtagelsen.

Hvad net_gateway egentlig navngiver

Profilposten for den undtagelse er én linje: route 198.51.100.77 255.255.255.255 net_gateway. Den første adresse er en dokumentationspladsholder for destinationen, masken gør den til en enkeltværtsrute, og det sidste token navngiver gateway-pladsholderen. OpenVPN opløser gateway-pladsholdere, når den installerer ruter. vpn_gateway betyder tunnelens egen gateway, den fjerne side af VPN-forbindelsen. net_gateway betyder den standardgateway, værten havde, før VPN'en ændrede noget, hvilket normalt er den lokale router på det fysiske netværk.

En tredje pladsholder, remote_host, henviser til VPN-serverens adresse, og den findes, så tunnelen kan nå serveren ad den fysiske vej. At forveksle disse tre er den mest almindelige grund til, at en undtagelse ender det forkerte sted eller slet ikke installeres.

Værdien læses ved forbindelsestidspunktet, ikke skrevet ind i filen. Hvis maskinen flytter til et andet netværk, ændres gatewayen før VPN'en, og ruten følger den nye. Det er normalt det, du ønsker, men det betyder også, at undtagelsens adfærd afhænger af det netværk, klienten startede fra.

Hvorfor en værtsrute vinder over tunnelens standardrute

Routing afgøres af det mest specifikke matchende præfiks. redirect-gateway def1 erstatter normalt ikke standardruten; den tilføjer to halvdele, en rute for den nederste halvdel af adresseområdet og en for den øverste halvdel, så den oprindelige standardrute bevares til andre formål. Disse halvdele er bredere end en enkelt adresse.

En rute for én adresse med maske 255.255.255.255 er en /32, hvilket er så specifikt, som IPv4 kan blive. Når en pakke til den adresse vurderes, matcher /32 og vinder uanset, hvilken rute der blev installeret først. Det er mekanismen bag undtagelsen, og den virker ens på Linux, macOS og Windows, så længe ruten faktisk findes.

Windows tilføjer en anden dimension. Når to ruter er lige specifikke, vinder den med den lavere metrik, og en VPN-adapter kan bære en grænseflademetrik, der ændrer resultatet. En /32 er stadig mere specifik end halvdelene, så undtagelsen holder normalt, men en forældet rute fra en tidligere session kan give et forvirrende resultat, hvis den er lige så specifik.

Hvad undtagelsen ikke dækker

DNS er det første hul. Klienten kan skubbe interne resolverindstillinger, og styresystemet vil fortsætte med at bruge dem til opslag. Et program, der opløser et navn, før det forbinder, kan få en intern adresse til en tjeneste, der burde gå direkte, eller en ekstern adresse, der opløses korrekt, men derefter snubler over det næste hul.

IPv6 er det andet. Rutedirektivet håndterer kun IPv4. En destination med dobbelt stak kan foretrække IPv6, som følger tunnelen eller værtens IPv6-standardrute afhængigt af politik, så undtagelsen for IPv4 aldrig kommer i spil. Du har brug for en matchende IPv6-rute eller en bevidst beslutning om at deaktivere IPv6 for den klient.

Programomfang er det tredje. Reglen er destinationsbaseret, så enhver proces, der forbinder til den adresse, bruger den direkte vej, uanset om det er den, du havde i tankerne. Omvendt kan et websted svare fra flere adresser, så en undtagelse for én /32 undtager ikke webstedet. Hvis det egentlige krav er routing for hvert program, er Community-klientens rutetabel det forkerte værktøj.

Kontroller undtagelsen uden at narre dig selv

Begynd med den installerede rute, ikke med en browser. På Linux kan du spørge kernen, hvilken rute og næste hop den vil bruge til den specifikke adresse; på Windows kan du læse rutetabellen for den /32. Bekræft, at gatewayen er den fysiske og ikke tunnelen. Hvis posten mangler, blev profilen ikke anvendt, eller klienten havde ikke rettigheden til at ændre ruter.

Test derefter to destinationer. En anmodning til den undtagne adresse bør forlade via den fysiske grænseflade, og en anmodning til en intern kontroladresse bør stadig bruge tunnelen. At teste kun den undtagne adresse beviser intet om resten af tunnelen, og at teste et offentligt websted tester, hvilken adresse det websted blev opløst til, hvilket måske ikke er den i reglen.

Kontroller til sidst de styringer, der kan overtrumfe ruten. En kill switch på klientsiden eller en Windows-indstilling block-outside-dns kan forbyde direkte trafik, hvilket viser sig som en forbindelse, der fejler, selv om ruten er korrekt. Deaktiver ikke disse styringer for at få undtagelsen til at se ud, som om den virker; hvis politikken forbyder den direkte vej, er undtagelsen et designproblem for den, der ejer VPN-tjenesten.

Kontroller igen efter genopkobling eller netværksskift, fordi gatewayen før VPN'en og den tilgængelige vej er egenskaber ved øjeblikket, ikke ved profilen.