Wéi een eenzel IPv4-Zil baussent engem OpenVPN-Tunnel schéckt

Déi meescht Volltunnel-Setupen schécken all Paket duerch d'VPN, an redirect-gateway ass d'Direktiv, déi dat méiglech mécht. Eng eenzel Destinatioun kann awer nach ëmmer ausgeschloss ginn. Eng Host-Route fir déi Adress mat dem net_gateway-Platzhalter ze addéieren seet dem Client, datt hien se iwwer de urspréngleche Gateway vun der Maschinn erreecht, während alles anescht weider den Tunnel benotzt.

D'Linn gesäit harmlos aus an ass et dacks, awer si entscheet nëmmen eng Fro: wou d'Pakete fir genee déi IPv4-Adress higinn. Si ännert weder DNS nach IPv6 nach d'Firewall-Politik oder wéi ee Prozess d'Verbindung opgemaach huet, an all dat kann d'Ausnam stëll zunichte maachen.

Wat net_gateway tatsächlech nennt

Den Profil-Antrag fir déi Ausnam ass eng Linn: route 198.51.100.77 255.255.255.255 net_gateway. Déi éischt Adress ass en Dokumentatiouns-Platzhalter fir d'Destinatioun, d'Mask mécht eng Eenzehost-Route draus, an de leschte Token nennt de Gateway-Platzhalter. OpenVPN léist Gateway-Platzhalter op, wann et Route installéiert. vpn_gateway bedeit den eegene Gateway vum Tunnel, déi wäit Säit vun der VPN-Verbindung. net_gateway bedeit den Standard-Gateway, deen den Host hat, ier d'VPN eppes geännert huet, wat normalerweis de lokale Router am physesche Netzwierk ass.

En drëtte Platzhalter, remote_host, bezitt sech op d'Adress vum VPN-Server, an en existéiert, datt den Tunnel de Server iwwer de physesche Wee erreeche kann. Dës dräi ze verwiesselen ass déi heefegst Ursaach, datt eng Ausnam op déi falsch Plaz geet oder guer net installéiert gëtt.

De Wäert gëtt beim Verbierwen gelies, net an de Fichier geschriwwen. Wann d'Maschinn an en anert Netzwierk geet, ännert sech de Gateway virun der VPN an d'Route follegt deem neien. Dat ass normalerweis wat dir wëllt, awer et heescht och, datt d'Verhalen vun der Ausnam vum Netzwierk ofhänkt, vun deem de Client gestart ass.

Firwat eng Host-Route de Standard vum Tunnel gewënnt

Routing gëtt vum spezifeschste passende Prefix entscheet. redirect-gateway def1 ersetzt normalerweis net de Standardroute; et füügt zwou Hälften derbäi, eng Route fir déi ënnescht Halschent vum Adressraum an eng fir déi iewescht, sou datt den ursprénglechen Standardroute fir aner Zwecker erhale bleift. Déi Hälften si breet wéi eng eenzel Adress.

Eng Route fir eng Adress mat der Mask 255.255.255.255 ass eng /32, wat sou spezifesch ass wéi IPv4 ka ginn. Wann e Paket fir déi Adress evaluéiert gëtt, passt d'/32 an gewënnt onofhängeg dovun, wéi eng Route als éischt installéiert gouf. Dat ass de Mechanismus hannert der Ausnam, an en funktionéiert genee esou op Linux, macOS a Windows, soulaang d'Route wierklech do ass.

Windows füügt eng zweet Dimensioun derbäi. Wann zwou Route gläich spezifesch sinn, gewënnt déi mat der méi niddereger Metrik, an e VPN-Adapter kann eng Interface-Metrik droen, déi d'Resultat ännert. Eng /32 ass nach ëmmer spezifescher wéi d'Hälften, also hält d'Ausnam normalerweis, awer eng al Route aus enger fréierer Sëtzung kann e verwirrend Resultat ginn, wann se gläich spezifesch ass.

Wat d'Ausnam net deckt

DNS ass déi éischt Lück. De Client kann intern Resolver-Astellungen duerchdrécken, an d'Betribssystem wäert se weider fir Ufroe benotzen. Eng Applikatioun, déi en Numm virum Verbierwen opléist, kann eng intern Adress fir engem Service kréien, dee direkt soll goen, oder eng extern Adress, déi richteg opgeléist gëtt, awer dann iwwer déi nächst Lück stolpert.

IPv6 ass déi zweet. D'Route-Direktiv behännelt nëmmen IPv4. Eng Dual-Stack-Destinatioun kann IPv6 virzéien, dat jee no Politik dem Tunnel oder dem IPv6-Standardroute vum Host follegt, sou datt d'IPv4-Ausnam ni a Kraaft trëtt. Dir braucht eng passend IPv6-Route oder eng bewosst Entscheedung, IPv6 fir dee Client auszeschalten.

Den Applikatiounsumfang ass den drëtten. D'Regel baséiert op der Destinatioun, also benotzt all Prozess, dee sech mat där Adress verbënnt, de direkte Wee, egal ob et dee war, deen dir am Kapp hat. Ëmgekéiert kann eng Websäit aus verschiddenen Adressen äntweren, also eng /32 auszeschléissen schléisst d'Säit net aus. Wann déi richteg Fuerderung Routing pro Applikatioun ass, ass d'Routentabelle vum Community-Client dat falscht Instrument.

D'Ausnam kontrolléieren ouni sech selwer ze täuschen

Fänkt mat der installéierter Route un, net mam Browser. Frot op Linux de Kernel, wéi eng Route an wéi en nächsten Hopp en fir déi spezifesch Adress benotzt; liest op Windows d'Routentabelle fir déi /32. Bestätegt, datt de Gateway de physeschen an net den Tunnel ass. Wann den Antrag fehlt, gouf de Profil net ugewannt oder de Client hat net d'Recht, Route z'änneren.

Test dann zwou Destinatiounen. Eng Ufro un déi ausgeschloss Adress soll iwwer de physeschen Interface erausgoen, an eng Ufro un eng intern Kontrolladress soll nach ëmmer den Tunnel benotzen. Nëmmen déi ausgeschloss Adress ze testen beweist näischt iwwer de Rescht vum Tunnel, an eng ëffentlech Websäit ze testen test d'Adress, op déi déi Säit opgeléist gouf, déi vläicht net déi aus der Regel ass.

Schlussendlech kontrolléiert d'Kontrollen, déi d'Route kënnen iwwerstëmmen. En Kill Switch op der Clientsäit oder eng Windows-Astellung block-outside-dns kann direkten Traffic verbidden, wat sech als Verbindung weist, déi feelt, obwuel d'Route richteg ass. Deaktivéiert déi Kontrollen net, fir d'Ausnam schéngen ze maachen, datt se funktionéiert; wann d'Politik de direkte Wee verbitt, ass d'Ausnam en Designproblem fir de Besëtzer vum VPN-Service.

Kontrolléiert nach eng Kéier nom Neiverbannen oder Netzwierkwiessel, well de Gateway virun der VPN an de verfügbare Wee Eegeschafte vum Moment sinn, net vum Profil.