Hvad bypass-dhcp egentlig tilføjer en OpenVPN-ruteplan

En profil med redirect-gateway def1 bypass-dhcp kombinerer en tilsidesættelse af IPv4-standardruten med én snæver undtagelse. Folk læser det sidste ord og forventer en generel løsning på mobile forbindelser og bruger så en eftermiddag på en DHCP-teori, som flaget aldrig har understøttet. Hver del gør én ting, og undtagelsen er meget mindre end sit ry.

Skil flagene ad, før du tilskriver en fejl, der kun optræder på mobil, adressetildelingen. De to halvdele af den streng har intet med hinanden at gøre.

To flag, to uafhængige opgaver

Med def1 tilføjer klienten to IPv4-halvstandardruter i stedet for at udskifte den standardrute, der allerede findes. 0.0.0.0/1 dækker den nederste halvdel af adresseområdet og 128.0.0.0/1 den øverste halvdel, så sammen når de enhver destination, mens hver af dem forbliver mere specifik end 0.0.0.0/0. Den oprindelige standardrute bliver derfor i tabellen uden at vinde de opslag, hvilket holder den gamle gateway tilgængelig for alt, hvad klienten selv ruterr eksplicit. Det efterlader også to overlappende standardruter i tabellen, og derfor kan en ruteudskrift se mærkeligere ud, end profilen antyder.

bypass-dhcp er separat og rører slet ikke standardruten. OpenVPN 2.6-manualen beskriver det som tilføjelsen af en direkte rute til en DHCP-server, der ikke ligger på det lokale undernet, så leasingtrafik forlader uden om tunnelen, og bemærker, at adfærden er implementeret på Windows-klienter og muligvis ikke findes andre steder.

Grunden til, at det findes, er mekanisk. Når først halvstandardruterne fanger udgående trafik, vil en DHCP-fornyelse rettet mod en server på det fysiske netværk blive routet ind i tunnelen, medmindre noget fastlåser den adresse til den rigtige grænseflade. Flaget fastlåser den.

Hvad undtagelsen egentlig dækker

En illustrativ tabel efter en vellykket forbindelse viser formen: to halvstandardruter gennem tunnelen og én værtsrute til DHCP-serveren gennem den fysiske gateway. Læs den som en form, ikke som dine egne adresser.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Den tredje linje nævner én destination. Det er ikke en resolverindstilling, ikke en generel tilladelse til det lokale netværk og ikke en udgangsregel på serveren. En telefon på en mobilforbindelse har måske ingen DHCP-server, som klienten kan identificere på denne måde, og derfor ændrer flaget intet der.

Kontrollér, hvad klienten faktisk installerede

Skel mellem en indstilling, der er skrevet i en profil, en indstilling, som serveren tilbyder, og en rute, som forbindelsens ejer faktisk anvendte. En klient, der afviser et ikke-understøttet flag, kan beholde resten af konfigurationen, så tunnelen kommer op, og undtagelsen mangler simpelthen. Læs klientens egen log og den resulterende rutetabel i stedet for at antage, at linjen i filen trådte i kraft. Tre af disse kan være sande på én gang, og kun den sidste ændrer, hvor pakkerne faktisk går hen.

Hold ruten til VPN-endepunktet brugbar samtidig. Den endepunktsundtagelse er et andet krav end DHCP-undtagelsen, og uden den kan tunnelen fange den transport, der holder den i live.

For en applikationsdestination skal du undersøge det effektive opslag i den sammenhæng, hvor det fejler. Mere specifikke lokale ruter, policy-routing og udelukkelser per applikation ændrer alle svaret, så tilstedeværelsen af to halvstandardruter er ikke en fortegnelse over hver strøm.

Resten af vejen ligger ikke i dette flag

Serveren har stadig brug for tilladelse til at videresende klientens internettrafik og en udgangsordning, der kan sende den tilbage. Ingen rute på klientsiden skaber manglende videresendelse eller kildetranslation på serveren, og intet flag erstatter en fungerende returvej.

Navneopløsning og IPv6 har hver brug for deres egen politik. En IPv4-tilsidesættelse peger hverken resolveren mod en server på tunnelsiden eller etablerer IPv6-dækning, og en klient, der kun omdirigerer v4, lader en v6-vej være urørt.

Sammenlign én godkendt uskadelig anmodning ad en fungerende og en fejlende adgangsvej med profilen og destinationen holdt fast. Notér, om forskellen ligger i navneopløsning, tunneloprettelse, rutevalg eller videresendt trafik, og gem svaret sammen med profilen. Den registrering er det, der forhindrer den næste person i at bebrejde DHCP et problem, som det ikke kan nå.