Wat bypass-dhcp feitlik tafoeget oan in OpenVPN-rûteplan

In profyl mei redirect-gateway def1 bypass-dhcp kombinearret in oerskriuwing fan 'e standert IPv4-rûte mei ien smelle útsûndering. Minsken lêze it lêste wurd en ferwachtsje in algemiene oplossing foar mobyle ferbiningen, en bringe dan in middei troch oan in DHCP-teory dy't de flag nea stipe hat. Elk part docht ien ding, en de útsûndering is folle lytser as har reputaasje.

Skied de flags foardat jo in flater dy't allinnich op mobyl foarkomt taskriuwe oan adresopdracht. De twa helten fan dy string hawwe neat mei elkoar te meitsjen.

Twa flags, twa losse taken

Mei def1 foeget de klant twa IPv4-healstandertrûtes ta ynstee fan 'e standertrûte te ferfangen dy't der al is. 0.0.0.0/1 beslacht de ûnderste helte fan 'e adresromte en 128.0.0.0/1 de boppeste helte, sadat se tegearre elk bestimming berikke wylst elk spesifiker bliuwt as 0.0.0.0/0. De oarspronklike standertrûte bliuwt dêrom yn 'e tabel sûnder dy sykaksjes te winnen, wat de âlde gateway berikber hâldt foar alles wat de klant eksplisyt rûtet. It lit ek twa oerlaapjende standertrûtes yn 'e tabel, en dêrom kin in rûte-útdraai frjemder lykje as't it profyl suggerearret.

bypass-dhcp is apart en rekket de standertrûte hielendal net. De OpenVPN 2.6-hantlieding beskriuwt it as it tafoegjen fan in direkte rûte nei in DHCP-tsjinner dy't net op it lokale subnet leit, sadat leaseferkear bûten de tunnel giet, en merkt op dat it gedrach op Windows-klanten ymplemintearre is en earne oars miskien net beskikber is.

De reden dat it bestiet is meganysk. Sadree't de healstandertrûtes útgeand ferkear fange, soe in DHCP-ferfanging rjochte op in tsjinner op it fysike netwurk de tunnel yn rûte wurde, útsein as eat dat adres oan 'e echte ynterface fêstset. De flag set it fêst.

Wêr't de útsûndering feitlik op beheind is

In yllustrative tabel nei in slagge ferbining lit de foarm sjen: twa healstandertrûtes troch de tunnel en ien hostrûte foar de DHCP-tsjinner troch de fysike gateway. Lês it as in foarm, net as jo eigen adressen.

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

Dy tredde rigel neamt ien bestimming. It is gjin ynstelling fan 'e resolvers, gjin algemiene tastimming foar it lokale netwurk en gjin útgongsregel op 'e tsjinner. In tillefoan op in mobyl netwurk hat miskien gjin DHCP-tsjinner dy't de klant sa identifisearje kin, en dêrom feroaret de flag dêr neat.

Kontrolearje wat de klant wier ynstallearre hat

Untskiede in opsje skreaun yn in profyl, in opsje oanbean troch de tsjinner en in rûte dy't de eigner fan 'e ferbining wier tapast hat. In klant dy't in net-stipe flag wegeret, kin de rest fan 'e konfiguraasje hâlde, sadat de tunnel opkomt en de útsûndering gewoan ôfwêzich is. Lês it eigen log fan 'e klant en de resultearjende rûtetabel ynstee fan oan te nimmen dat de rigel yn it bestân fan krêft wurden is. Trije dêrfan kinne tagelyk wier wêze, en allinnich de lêste feroaret wêr't pakketten wier hinne geane.

Hâld de rûte nei it VPN-einpunt tagelyk brûkber. Dy einpuntútsûndering is in oare eask as de DHCP-útsûndering, en sûnder dy kin de tunnel it ferfier fange dat him oanhâldt.

Foar in applikaasjebestimming, ûndersykje de effektive sykaksje yn 'e kontekst wêr't it misgiet. Spesifiker lokale rûtes, beliedsrûtering en útslutings per applikaasje feroarje allegear it antwurd, sadat de oanwêzigens fan twa healstandertrûtes gjin ynhâldsopjefte fan elke stream is.

De rest fan it paad sit net yn dizze flag

De tsjinner hat noch altyd tastimming nedich om it ynternetferkear fan 'e klant troch te stjoeren en in útgongsregeling dy't it weromstjoere kin. Gjin rûte oan 'e klantkant makket ûntbrekkende foarstjoering of boarnfertaling op 'e tsjinner, en gjin flag ferfangt in wurkjende weromwei.

Namme-oplossing en IPv6 hawwe elk har eigen belied nedich. In IPv4-oerskriuwing rjochtet de resolvers noch op in tsjinner oan 'e tunnelkant, noch makket it IPv6-dekking, en in klant dy't allinnich v4 omleit lit in v6-paad ûnoantaaste.

Fergelykje ien goedkarde ûnskuldige oanfraach oer in wurkjend en in misgjend tagongspaad, wylst it profyl en de bestimming fêst bliuwe. Skriuw op oft it ferskil yn namme-oplossing, tunnelynstelling, rûtekar of trochstjoerd ferkear sit, en bewarje it antwurd by it profyl. Krekt dy notysje hâldt de folgjende persoan tsjin om DHCP de skuld te jaan foar in probleem dat it net berikke kin.