Mitä bypass-dhcp todella lisää OpenVPN:n reittisuunnitelmaan

redirect-gateway def1 bypass-dhcp -profiili yhdistää IPv4-oletusreitin ohituksen yhteen kapeaan poikkeukseen. Ihmiset lukevat viimeisen sanan ja odottavat yleistä ratkaisua matkapuhelinyhteyksiin, ja viettävät sitten iltapäivän DHCP-teorialla, jota lippu ei koskaan tukenut. Jokainen osa tekee yhden asian, ja poikkeus on paljon mainettaan pienempi.

Pura liput osiin ennen kuin osoitat vain matkapuhelinverkossa ilmenevän vian osoitteiden jakamiseen. Tuon merkkijonon kahdella puoliskolla ei ole mitään tekemistä toistensa kanssa.

Kaksi lippua, kaksi erillistä tehtävää

def1-asetuksella asiakas lisää kaksi IPv4-puolio-oletusreittiä sen sijaan, että se vaihtaisi jo olemassa olevan oletusreitin. 0.0.0.0/1 kattaa osoiteavaruuden alaosan ja 128.0.0.0/1 yläosan, joten yhdessä ne tavoittavat jokaisen kohteen, samalla kun kumpikin pysyy tarkempana kuin 0.0.0.0/0. Alkuperäinen oletusreitti jää siis tauluun voittamatta näitä hakuja, mikä pitää vanhan yhdyskäytävän tavoitettavana kaikelle, mitä asiakas reitittää nimenomaisesti. Se jättää tauluun myös kaksi päällekkäistä oletusreittiä, minkä vuoksi reittituloste voi näyttää oudommalta kuin profiili antaa ymmärtää.

bypass-dhcp on erillinen eikä koske oletusreittiin lainkaan. OpenVPN 2.6 -käsikirja kuvaa sen suoran reitin lisäämisenä DHCP-palvelimelle, joka ei ole paikallisessa aliverkossa, jolloin vuokraliikenne poistuu tunnelin ulkopuolelta, ja huomauttaa, että käyttäytyminen on toteutettu Windows-asiakkaissa eikä välttämättä ole saatavilla muualla.

Sen olemassaolon syy on mekaaninen. Kun puolio-oletusreitit kaappaavat lähtevän liikenteen, fyysisen verkon palvelimelle suunnattu DHCP-uudistus reititettäisiin tunneliin, ellei jokin kiinnitä tuota osoitetta todelliseen rajapintaan. Lippu kiinnittää sen.

Mihin poikkeus oikeastaan rajautuu

Havainnollistava taulu onnistuneen yhteyden jälkeen näyttää muodon: kaksi puolio-oletusreittiä tunnelin kautta ja yksi kohdeverkkoreitti DHCP-palvelimelle fyysisen yhdyskäytävän kautta. Lue se muotona, älä omina osoitteinasi.

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

Kolmas rivi nimeää yhden kohteen. Se ei ole resolverin asetus, ei yleinen lupa paikallisverkkoon eikä palvelimen lähtösääntö. Matkapuhelinverkon puhelimella ei ehkä ole DHCP-palvelinta, jonka asiakas voisi tunnistaa tällä tavalla, minkä vuoksi lippu ei muuta siellä mitään.

Tarkista, mitä asiakas todella asensi

Erottele profiiliin kirjoitettu vaihtoehto, palvelimen tarjoama vaihtoehto ja reitti, jonka yhteyden omistaja todella otti käyttöön. Asiakas, joka hylkää tukemattoman lipun, voi pitää muun kokoonpanon, joten tunneli nousee ja poikkeus yksinkertaisesti puuttuu. Lue asiakkaan oma loki ja syntyvä reititystaulu sen sijaan, että olettaisit tiedoston rivin tulleen voimaan. Kolme näistä voi olla totta samaan aikaan, ja vain viimeinen muuttaa sitä, minne paketit todella menevät.

Pidä reitti VPN-päätepisteeseen käyttökelpoisena samanaikaisesti. Tämä päätepisteen poikkeus on eri vaatimus kuin DHCP-poikkeus, ja ilman sitä tunneli voi kaapata sen ylläpitämän siirtoyhteyden.

Sovelluskohteen osalta tutki tehokas haku siinä yhteydessä, jossa se epäonnistuu. Tarkemmat paikalliset reitit, käytäntöperusteinen reititys ja sovelluskohtaiset poissulkemiset muuttavat kaikki vastausta, joten kahden puolio-oletusreitin olemassaolo ei ole luettelo jokaisesta virtauksesta.

Loput polusta ei ole tässä lipussa

Palvelin tarvitsee edelleen luvan välittää asiakkaan internettiliikennettä ja lähtöjärjestelyn, joka voi palauttaa sen. Mikään asiakaspuolen reitti ei luo puuttuvaa välitystä tai lähdeosoitteen käännöstä palvelimelle, eikä mikään lippu korvaa toimivaa paluureittiä.

Nimien selvitys ja IPv6 tarvitsevat kumpikin oman käytäntönsä. IPv4-ohitus ei ohjaa resolveria tunnelin puoleiselle palvelimelle eikä luo IPv6-kattavuutta, ja asiakas, joka ohjaa uudelleen vain v4:n, jättää v6-reitin koskemattomaksi.

Vertaa yhtä hyväksyttyä vaaratonta pyyntöä toimivalla ja epäonnistuvalla pääsypolulla pitäen profiili ja kohde muuttumattomina. Kirjaa, onko ero nimien selvityksessä, tunnelin muodostuksessa, reitin valinnassa vai välitetyssä liikenteessä, ja säilytä vastaus profiilin yhteydessä. Juuri tämä kirjaus estää seuraavaa henkilöä syyttämästä DHCP:tä ongelmasta, johon se ei yllä.