Què afegeix realment bypass-dhcp a un pla de rutes d'OpenVPN

Un perfil que porta redirect-gateway def1 bypass-dhcp combina una substitució de la ruta IPv4 per defecte amb una excepció molt estreta. La gent llegeix l'última paraula i espera una solució general per a les connexions mòbils, i després passa una tarda amb una teoria DHCP que el flag mai no ha suportat. Cada part fa una sola cosa, i l'excepció és molt més petita que la seva reputació.

Separeu els flags abans d'atribuir un error que només passa amb dades mòbils a l'assignació d'adreces. Les dues meitats d'aquesta cadena no tenen res a veure l'una amb l'altra.

Dos flags, dues tasques sense relació

Amb def1, el client afegeix dues mitges rutes IPv4 per defecte en lloc de substituir la ruta per defecte que ja hi ha. 0.0.0.0/1 cobreix la meitat inferior de l'espai d'adreces i 128.0.0.0/1 la meitat superior, de manera que juntes arriben a qualsevol destinació mentre cadascuna continua sent més específica que 0.0.0.0/0. La ruta original per defecte, per tant, es queda a la taula sense guanyar aquestes consultes, cosa que manté la passarel·la antiga accessible per a tot el que el client encamina explícitament. També deixa dues rutes per defecte superposades a la taula, i per això un bolcat de rutes pot semblar més estrany del que suggereix el perfil.

bypass-dhcp és a part, i no toca la ruta per defecte de cap manera. El manual d'OpenVPN 2.6 el documenta com l'addició d'una ruta directa cap a un servidor DHCP que no és a la subxarxa local, de manera que el trànsit de concessió surt fora del túnel, i assenyala que aquest comportament s'implementa als clients Windows i pot no estar disponible enlloc més.

La raó de la seva existència és mecànica. Un cop les mitges rutes per defecte capturen el trànsit de sortida, una renovació DHCP adreçada a un servidor de la xarxa física s'encaminaria cap dins del túnel tret que alguna cosa fixi aquesta adreça a la interfície real. El flag la fixa.

A què s'aplica realment l'excepció

Una taula il·lustrativa després d'una connexió correcta mostra la forma: dues mitges rutes per defecte a través del túnel i una ruta d'amfitrió per al servidor DHCP a través de la passarel·la física. Llegiu-la com una forma, no com les vostres adreces.

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

Aquesta tercera línia anomena una sola destinació. No és una configuració del resolutor, no és un permís general per a la xarxa local i no és una regla de sortida al servidor. Un telèfon amb un portador mòbil pot no tenir cap servidor DHCP que el client pugui identificar d'aquesta manera, i per això el flag no hi canvia res.

Comproveu què ha instal·lat realment el client

Distingiu una opció escrita en un perfil, una opció oferta pel servidor i una ruta que l'amo de la connexió ha aplicat de debò. Un client que rebutja un flag no suportat pot conservar la resta de la configuració, així que el túnel s'aixeca i l'excepció simplement és absent. Llegiu el registre propi del client i la taula d'encaminament resultant en lloc de suposar que la línia del fitxer ha entrat en vigor. Tres d'aquestes coses poden ser certes alhora, i només la darrera canvia on van realment els paquets.

Mantingueu utilitzable alhora la ruta cap al punt final de la VPN. Aquesta excepció del punt final és un requisit diferent de l'excepció DHCP, i sense ella el túnel pot capturar el transport que el manté.

Per a una destinació d'aplicació, examineu la consulta efectiva en el context on falla. Rutes locals més específiques, encaminament per polítiques i exclusions per aplicació canvien totes la resposta, així que la presència de dues mitges rutes per defecte no és un inventari de cada flux.

La resta del camí no és en aquest flag

El servidor encara necessita permís per reenviar el trànsit d'internet del client i una disposició de sortida que el pugui retornar. Cap ruta al costat del client no crea un reenviament ni una traducció d'origen que faltin al servidor, i cap flag no substitueix un camí de tornada que funcioni.

La resolució de noms i l'IPv6 necessiten cadascuna la seva pròpia política. Una substitució d'IPv4 no apunta el resolutor cap a un servidor del costat del túnel ni estableix cobertura IPv6, i un client que només redirigeix v4 deixa intacte el camí v6.

Compareu una petició innòcua aprovada per un camí d'accés que funciona i un que falla, amb el perfil i la destinació fixos. Anoteu si la diferència és a la resolució de noms, a l'establiment del túnel, a la selecció de rutes o al trànsit reenviat, i guardeu la resposta amb el perfil. Aquest registre és el que evita que la propera persona culpi el DHCP d'un problema que no pot abastar.