Ce adaugă de fapt bypass-dhcp unui plan de rute OpenVPN

Un profil cu redirect-gateway def1 bypass-dhcp combină înlocuirea rutei IPv4 implicite cu o singură excepție îngustă. Oamenii citesc ultimul cuvânt și așteaptă o soluție generală pentru conexiunile mobile, apoi petrec o după-amiază cu o teorie DHCP pe care steagul nu a susținut-o niciodată. Fiecare parte face un singur lucru, iar excepția este mult mai mică decât reputația ei.

Despărțiți steagurile înainte de a atribui o defecțiune care apare doar în rețeaua mobilă alocării de adrese. Cele două jumătăți ale acelui șir nu au nimic de-a face una cu alta.

Două steaguri, două sarcini fără legătură

Cu def1, clientul adaugă două jumătăți de rute IPv4 implicite în loc să înlocuiască ruta implicită care există deja. 0.0.0.0/1 acoperă jumătatea inferioară a spațiului de adrese, iar 128.0.0.0/1 pe cea superioară, astfel încât împreună ajung la orice destinație, în timp ce fiecare rămâne mai specifică decât 0.0.0.0/0. Ruta implicită originală rămâne așadar în tabel fără a câștiga acele căutări, ceea ce menține poarta veche accesibilă pentru tot ce clientul rutează explicit. De asemenea, lasă în tabel două rute implicite suprapuse, motiv pentru care o listare de rute poate părea mai ciudată decât sugerează profilul.

bypass-dhcp este separat și nu atinge deloc ruta implicită. Manualul OpenVPN 2.6 îl descrie ca adăugarea unei rute directe către un server DHCP care nu se află în subrețeaua locală, astfel încât traficul de lease iese în afara tunelului, și notează că acest comportament este implementat pe clienții Windows și s-ar putea să nu fie disponibil altundeva.

Motivul existenței sale este mecanic. Odată ce jumătățile de rute implicite captează traficul de ieșire, o reînnoire DHCP adresată unui server din rețeaua fizică ar fi rutată în tunel dacă ceva nu fixează acea adresă pe interfața reală. Steagul o fixează.

La ce se limitează de fapt excepția

Un tabel ilustrativ după o conexiune reușită arată forma: două jumătăți de rute implicite prin tunel și o rută de gazdă pentru serverul DHCP prin poarta fizică. Citiți-l ca formă, nu ca adresele dumneavoastră.

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

A treia linie numește o singură destinație. Nu este o setare a resolverului, nu este o permisiune generală pentru rețeaua locală și nu este o regulă de ieșire pe server. Un telefon pe un operator mobil poate să nu aibă niciun server DHCP pe care clientul să îl identifice astfel, motiv pentru care steagul nu schimbă nimic acolo.

Verificați ce a instalat de fapt clientul

Distingeți o opțiune scrisă într-un profil, o opțiune oferită de server și o rută pe care proprietarul conexiunii a aplicat-o efectiv. Un client care respinge un steag neacceptat poate păstra restul configurației, așa că tunelul pornește și excepția pur și simplu lipsește. Citiți jurnalul clientului însuși și tabelul de rutare rezultat în loc să presupuneți că linia din fișier a intrat în vigoare. Trei dintre acestea pot fi adevărate simultan, iar doar ultima schimbă unde ajung de fapt pachetele.

Păstrați ruta către punctul final VPN utilizabilă în același timp. Acea excepție a punctului final este o cerință diferită de excepția DHCP, iar fără ea tunelul poate captura transportul care îl menține.

Pentru o destinație de aplicație, examinați căutarea efectivă în contextul în care eșuează. Rute locale mai specifice, rutarea pe politici și excluderile pe aplicație schimbă toate răspunsul, așa că prezența a două jumătăți de rute implicite nu este un inventar al fiecărui flux.

Restul traseului nu este în acest steag

Serverul are în continuare nevoie de permisiunea de a redirecționa traficul de internet al clientului și de o ieșire care îl poate returna. Nicio rută de pe partea clientului nu creează redirecționare sau traducere de sursă lipsă pe server, iar niciun steag nu înlocuiește o cale de întoarcere funcțională.

Rezolvarea numelor și IPv6 au nevoie fiecare de propria politică. O înlocuire IPv4 nu îndreaptă resolverul către un server din partea tunelului și nu stabilește acoperire IPv6, iar un client care redirecționează doar v4 lasă neatinsă o cale v6.

Comparați o cerere inofensivă aprobată pe o cale de acces funcțională și pe una defectă, ținând profilul și destinația fixe. Notați dacă diferența stă în rezolvarea numelor, în stabilirea tunelului, în selectarea rutei sau în traficul redirecționat, și păstrați răspunsul împreună cu profilul. Acea notă este ceea ce împiedică următoarea persoană să dea vina pe DHCP pentru o problemă la care acesta nu poate ajunge.