Que engade realmente bypass-dhcp a un plan de rutas de OpenVPN

Un perfil con redirect-gateway def1 bypass-dhcp combina unha substitución da ruta IPv4 predeterminada cunha única excepción moi estreita. A xente le a última palabra e espera unha solución xeral para conexións móbiles, e logo pasa unha tarde cunha teoría de DHCP que o indicador nunca admitiu. Cada parte fai unha cousa, e a excepción é moito menor que a súa reputación.

Separe os indicadores antes de atribuír un fallo que só ocorre con datos móbiles á asignación de enderezos. As dúas metades desa cadea non teñen nada que ver entre si.

Dous indicadores, dúas tarefas sen relación

Con def1, o cliente engade dúas medias rutas IPv4 predeterminadas en lugar de substituír a ruta predeterminada que xa existe. 0.0.0.0/1 cobre a metade inferior do espazo de enderezos e 128.0.0.0/1 a metade superior, así que xuntas chegan a calquera destino mentres cada unha segue a ser máis específica que 0.0.0.0/0. A ruta predeterminada orixinal queda por tanto na táboa sen gañar esas procuras, o que mantén accesible a vella pasarela para todo o que o cliente encamiña explicitamente. Tamén deixa dúas rutas predeterminadas solapadas na táboa, e por iso unha descarga de rutas pode parecer máis estraña do que suxire o perfil.

bypass-dhcp está á parte e non toca a ruta predeterminada en absoluto. O manual de OpenVPN 2.6 documéntao como a adición dunha ruta directa cara a un servidor DHCP que non está na subrede local, de xeito que o tráfico de concesión sae fóra do túnel, e sinala que o comportamento está implementado nos clientes Windows e pode non estar dispoñible noutros lugares.

A razón da súa existencia é mecánica. Unha vez que as medias rutas predeterminadas capturan o tráfico de saída, unha renovación de DHCP dirixida a un servidor da rede física encamiñaríase dentro do túnel a non ser que algo fixe ese enderezo á interface real. O indicador fíxao.

A que se limita realmente a excepción

Unha táboa ilustrativa tras unha conexión correcta mostra a forma: dúas medias rutas predeterminadas polo túnel e unha ruta de host para o servidor DHCP pola pasarela física. Léaa como unha forma, non como os seus propios enderezos.

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

Esa terceira liña nomea un só destino. Non é un axuste do resolvedor, non é un permiso xeral para a rede local e non é unha regra de saída no servidor. Un teléfono cun operador móbil pode non ter ningún servidor DHCP que o cliente poida identificar deste xeito, e por iso o indicador non cambia nada alí.

Comprobe que instalou realmente o cliente

Distinga entre unha opción escrita nun perfil, unha opción ofrecida polo servidor e unha ruta que o dono da conexión aplicou de verdade. Un cliente que rexeita un indicador non admitido pode conservar o resto da configuración, así que o túnel levanta e a excepción simplemente falta. Lea o rexistro propio do cliente e a táboa de encamiñamento resultante en lugar de supor que a liña do ficheiro surtiu efecto. Tres desas cousas poden ser certas ao mesmo tempo, e só a última cambia a onde van realmente os paquetes.

Manteña utilizable ao mesmo tempo a ruta cara ao extremo da VPN. Esa excepción do extremo é un requisito distinto da excepción de DHCP, e sen ela o túnel pode capturar o transporte que o mantén.

Para un destino de aplicación, examine a procura efectiva no contexto no que falla. Rutas locais máis específicas, o encamiñamento por políticas e as exclusións por aplicación cambian todas a resposta, así que a presenza de dúas medias rutas predeterminadas non é un inventario de cada fluxo.

O resto do camiño non está neste indicador

O servidor segue necesitando permiso para reenviar o tráfico de internet do cliente e unha disposición de saída que poida devolvelo. Ningunha ruta do lado do cliente crea un reenvío nin unha tradución de orixe que falten no servidor, e ningún indicador substitúe un camiño de volta que funcione.

A resolución de nomes e IPv6 necesitan cada unha a súa propia política. Unha substitución de IPv4 nin apunta o resolvedor a un servidor do lado do túnel nin establece cobertura IPv6, e un cliente que só redirixe v4 deixa intacto o camiño v6.

Compare unha petición inocua aprobada por un camiño de acceso que funciona e outro que falla, co perfil e o destino fixos. Anote se a diferenza está na resolución de nomes, no establecemento do túnel, na selección de rutas ou no tráfico reenviado, e garde a resposta xunto ao perfil. Ese rexistro é o que impide que a seguinte persoa culpe o DHCP dun problema que non pode alcanzar.