Kva bypass-dhcp faktisk legg til i ein OpenVPN-ruteplan

Ein profil med redirect-gateway def1 bypass-dhcp kombinerer ei overstyring av IPv4-standardruta med eitt smalt unntak. Folk les det siste ordet og ventar ei generell løysing for mobile samband, og brukar deretter ein ettermiddag på ein DHCP-teori som flagget aldri har støtta. Kvar del gjer éin ting, og unntaket er mykje mindre enn ryktet sitt.

Skil flagga frå kvarandre før du legg ei feil som berre kjem på mobil, på adressetildelinga. Dei to halvdelane av den strengen har ingenting med kvarandre å gjere.

To flagg, to uavhengige jobbar

Med def1 legg klienten til to IPv4-halvstandardruter i staden for å byte ut standardruta som alt finst. 0.0.0.0/1 dekkjer den nedre halvdelen av adresseområdet og 128.0.0.0/1 den øvre halvdelen, slik at dei saman når kvar destinasjon medan kvar av dei blir meir spesifikk enn 0.0.0.0/0. Den opphavlege standardruta blir difor verande i tabellen utan å vinne dei oppslaga, noko som held den gamle porten tilgjengeleg for alt klienten rutar eksplisitt. Det lèt òg to overlapping standardruter i tabellen, og difor kan ein ruteutskrift sjå rarare ut enn profilen antydar.

bypass-dhcp er åtskilt og rører ikkje standardruta i det heile. OpenVPN 2.6-handboka skildrar det som å leggje til ei direkte rute til ein DHCP-tenar som ikkje er på det lokale delnettet, slik at leasetrafikk går utanfor tunnelen, og nemner at åtferda er implementert på Windows-klientar og kanskje ikkje er tilgjengeleg andre stader.

Grunnen til at det finst er mekanisk. Når halvstandardrutene først fangar utgåande trafikk, vil ei DHCP-fornying retta mot ein tenar på det fysiske nettet bli ruta inn i tunnelen med mindre noko festar den adressa til det verkelege grensesnittet. Flagget festar henne.

Kva unntaket faktisk dekkjer

Ein illustrerande tabell etter ei vellukka tilkobling viser forma: to halvstandardruter gjennom tunnelen og éi vertsrute for DHCP-tenaren gjennom den fysiske porten. Les han som ei form, ikkje som dine eigne 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 linja namngjev éin destinasjon. Det er ikkje ei innstilling for resolvar, ikkje ei generell løyve for det lokale nettet og ikkje ein utgangsregel på tenaren. Ein telefon på eit mobilnett har kanskje ingen DHCP-tenar som klienten kan identifisere på denne måten, og difor endrar flagget ingenting der.

Kontroller kva klienten faktisk installerte

Skil mellom eit val som er skrive i ein profil, eit val som tenaren tilbyr, og ei rute som eigaren av tilkoblinga faktisk brukte. Ein klient som avviser eit flagg han ikkje støttar, kan halde på resten av konfigurasjonen, slik at tunnelen kjem opp og unntaket rett og slett manglar. Les loggen til klienten sjølv og den resulterande rutetabellen i staden for å gå ut frå at linja i fila vart sett i kraft. Tre av desse kan vere sanne samstundes, og berre den siste endrar kvar pakkane faktisk går.

Hald ruta til VPN-endepunktet brukbar samstundes. Det endepunktunntaket er eit anna krav enn DHCP-unntaket, og utan det kan tunnelen fange transporten som held han oppe.

For ein applikasjonsdestinasjon, gransk det effektive oppslaget i samanhengen der det sviktar. Meir spesifikke lokale ruter, policy-ruting og unntak per applikasjon endrar alle svaret, så tilstadeveringa av to halvstandardruter er ikkje ei oversikt over kvar straum.

Resten av vegen ligg ikkje i dette flagget

Tenaren treng framleis løyve til å videresende internettrafikken til klienten og ei utgangsordning som kan sende han tilbake. Inga rute på klientsida skapar manglande videresending eller kjeldeomsetjing på tenaren, og ingen flagg erstattar ein fungerande returveg.

Namneoppslag og IPv6 treng kvar sin policy. Ei IPv4-overstyring peikar ikkje resolvaren mot ein tenar på tunnelsida og etablerer ikkje IPv6-dekning, og ein klient som berre omdirigerer v4, lèt ein v6-veg vere urørt.

Samanlikn éin godkjend ufarleg førespurnad over ein fungerande og ein feilande tilgangsveg med profilen og destinasjonen haldne fast. Noter om skilnaden ligg i namneoppslag, tunneletablering, ruteval eller videresend trafikk, og oppbevar svaret saman med profilen. Den noteringa er det som hindrar den neste i å skulde på DHCP for eit problem det ikkje kan nå.