Hva bypass-dhcp faktisk tilfører en OpenVPN-ruteplan

En profil med redirect-gateway def1 bypass-dhcp kombinerer en overstyring av IPv4-standardruten med ett smalt unntak. Folk leser det siste ordet og forventer en generell løsning for mobile forbindelser, og bruker deretter en ettermiddag på en DHCP-teori som flagget aldri har støttet. Hver del gjør én ting, og unntaket er mye mindre enn ryktet sitt.

Skil flaggene fra hverandre før du tilskriver en feil som bare oppstår på mobil, adressetildelingen. De to halvdelene av den strengen har ingenting med hverandre å gjøre.

To flagg, to uavhengige jobber

Med def1 legger klienten til to IPv4-halvstandardruter i stedet for å bytte ut standardruten som allerede finnes. 0.0.0.0/1 dekker den nedre halvdelen av adresseområdet og 128.0.0.0/1 den øvre halvdelen, slik at de sammen når hver destinasjon mens hver av dem forblir mer spesifikk enn 0.0.0.0/0. Den opprinnelige standardruten blir derfor i tabellen uten å vinne de oppslagene, noe som holder den gamle gatewayen tilgjengelig for alt klienten ruter eksplisitt. Det etterlater også to overlappende standardruter i tabellen, og derfor kan en ruteutskrift se rarere ut enn profilen antyder.

bypass-dhcp er atskilt og rører ikke standardruten i det hele tatt. OpenVPN 2.6-håndboken beskriver det som å legge til en direkte rute til en DHCP-server som ikke er på det lokale delnettet, slik at lease-trafikk går utenfor tunnelen, og bemerker at atferden er implementert på Windows-klienter og kanskje ikke er tilgjengelig andre steder.

Grunnen til at det finnes er mekanisk. Når halvstandardrutene først fanger utgående trafikk, vil en DHCP-fornyelse rettet mot en server på det fysiske nettet bli rutet inn i tunnelen med mindre noe fester den adressen til det virkelige grensesnittet. Flagget fester den.

Hva unntaket faktisk dekker

En illustrerende tabell etter en vellykket tilkobling viser formen: to halvstandardruter gjennom tunnelen og én vertsrute for DHCP-serveren gjennom den fysiske gatewayen. Les 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 linjen navngir én destinasjon. Det er ikke en innstilling for resolvers, ikke en generell tillatelse for det lokale nettet og ikke en utgangsregel på serveren. En telefon på et mobilnett har kanskje ingen DHCP-server som klienten kan identifisere på denne måten, og derfor endrer flagget ingenting der.

Kontroller hva klienten faktisk installerte

Skill mellom et alternativ som er skrevet i en profil, et alternativ som serveren tilbyr, og en rute som eieren av tilkoblingen faktisk brukte. En klient som avviser et flagg den ikke støtter, kan beholde resten av konfigurasjonen, slik at tunnelen kommer opp og unntaket rett og slett mangler. Les klientens egen logg og den resulterende rutetabellen i stedet for å anta at linjen i filen trådte i kraft. Tre av disse kan være sanne samtidig, og bare den siste endrer hvor pakkene faktisk går.

Hold ruten til VPN-endepunktet brukbar samtidig. Det endepunktunntaket er et annet krav enn DHCP-unntaket, og uten det kan tunnelen fange transporten som holder den oppe.

For en applikasjonsdestinasjon, undersøk det effektive oppslaget i sammenhengen der det feiler. Mer spesifikke lokale ruter, policy-ruting og unntak per applikasjon endrer alle svaret, så tilstedeværelsen av to halvstandardruter er ikke en oversikt over hver strøm.

Resten av veien ligger ikke i dette flagget

Serveren trenger fortsatt tillatelse til å videresende klientens internettrafikk og en utgangsordning som kan sende den tilbake. Ingen rute på klientsiden skaper manglende videresending eller kildetranslasjon på serveren, og ingen flagg erstatter en fungerende returvei.

Navneoppslag og IPv6 trenger hver sin policy. En IPv4-overstyring peker ikke resolveren mot en server på tunnelsiden og etablerer ikke IPv6-dekning, og en klient som bare omdirigerer v4, lar en v6-vei være urørt.

Sammenlign én godkjent ufarlig forespørsel over en fungerende og en feilende tilgangsvei med profilen og destinasjonen holdt fast. Noter om forskjellen ligger i navneoppslag, tunneletablering, rutevalg eller videresendt trafikk, og oppbevar svaret sammen med profilen. Den noteringen er det som hindrer den neste i å skylde på DHCP for et problem det ikke kan nå.