Que impide realmente route-nopull de OpenVPN que o servidor envíe
route-nopull descarta as rutas e opcións DHCP enviadas, non o handshake. Escolle entre el, pull-filter ou nada, e despois engade as rutas ti mesmo.
Puxeches route-nopull nun perfil de cliente para evitar que o túnel tragase a túa ruta predeterminada, e agora a subrede da oficina é inalcanzable mentres o cliente segue dicindo que está conectado. Ambas as observacións son certas e nada fallou. O indicador dille ao cliente que omita as rutas e as entradas DHCP que envía o servidor, unha instrución máis estreita do que a maioría espera ao engadila. O que queda é un túnel funcional sen opinión sobre que destinos deben usalo.
Ese oco é toda a decisión da que trata este artigo. Ou o servidor describe a rede, ou faino o cliente, e o indicador entrega esa tarefa ao cliente sen facer nada dela por ti.
Que apaga o indicador ao conectar
Un cliente OpenVPN que tira normalmente recibe do servidor tras a autenticación un paquete: rutas, unha redirección da pasarela predeterminada, servidores DNS e unhas cantas directivas de axuste. Con route-nopull en vigor, o cliente segue aceptando a sesión, segue verificando certificados, segue negociando cifrados e keepalives, e segue levantando a interface. O que descarta é a aplicación das liñas route enviadas e das liñas dhcp-option enviadas, DNS incluído.
A confusión vén dun indicador verde xunto a unha aplicación morta. O túnel existe; a correspondencia de destinos con ese túnel non. Nada no panel de estado do cliente distingue «conectado e encamiñando» de «conectado e inerte», porque desde o punto de vista do túnel ambos son o mesmo estado.
Por que un túnel vivo pode non encamiñar nada
A interface aparece coa súa propia dirección e, nunha ligazón punto a punto, a miúdo non ten nada máis específico que unha ruta de host cara ao par. Unha subrede privada só se volve alcanzable cando algunha ruta apunta a esa interface co prefixo correcto, e co envío desactivado esa ruta nunca chega. O perfil descargado tampouco adoita axudar, porque se escribiu asumindo que o servidor proporcionaría exactamente esta información. Por iso a interface pode parecer san mentres a subrede segue escura.
Ler o perfil, por tanto, demostra moi pouco. Le o estado en execución, na máquina conectada:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10Unha dirección sen ruta de subrede no segundo comando é a sinatura deste problema. O terceiro comando responde entón a pregunta que de verdade importa aos usuarios, porque informa da interface que o núcleo elixiría para un destino concreto en lugar da lista que esperabas que usase. Se responde pola túa ligazón física, o túnel non está no camiño en absoluto.
A resolución de nomes falla por un motivo relacionado, non por un separado. As entradas dhcp-option DNS enviadas omítense co mesmo indicador, así que as consultas de hosts internos van ao resolutor que proporcionase a rede local. Ese resolutor non ten zona para a oficina, así que a consulta falla ou devolve unha resposta pública, e o fallo parece un problema do servidor cando é un problema de configuración do cliente. Probar unha dirección antes que un nome é o que separa ambas as cousas.
Elixir entre o indicador e un filtro de prefixo
As dúas opcións resolven formas distintas da mesma queixa, e elixir mal é o que produce o estado de conectado pero inútil. Unha substitúe a política enviada por completo, mentres que a outra edítaa por prefixo. A táboa dá a versión curta, e o parágrafo seguinte cobre a parte que pilla a xente.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter é un comparador de prefixos con tres verbos, así que pode aceptar unha familia de liñas, ignoralas en silencio ou rexeitar a conexión directamente cando aparece un prefixo. Ese último comportamento é o que merece coñecerse: unha regra de rexeitamento converte un desacordo de política nun handshake fallido en lugar dunha omisión silenciosa. O manual de OpenVPN 2.6 enumera os prefixos aceptados e a semántica exacta de cada verbo.
Un camiño intermedio habitual é rexeitar só redirect-gateway e deixar que as rutas da oficina e o DNS cheguen como se pretende. Iso mantén o envío funcionando para as partes que o servidor entende mellor ca ti, ao tempo que evita a única liña que se faría coa túa ruta predeterminada.
Engadir rutas e un resolutor a man
Se mantés o indicador, o perfil ten que dicir o que diría o servidor. As directivas route do lado do cliente aplícanse despois de establecer a conexión, así que funcionan xunto ao indicador en lugar de quedar bloqueadas por el. Ponas no perfil, non nunha liña de ordes interactiva, ou a próxima reconexión non reproducirá o estado funcional.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53A liña DNS está nunha posición incómoda: é unha directiva do lado do cliente, pero algúns clientes só a aplican mediante a integración DNS da plataforma, que pode sobrescribila cando cambia a ligazón. Nun host con systemd, fixar o resolutor directamente na interface do túnel é máis previsible que esperar que o cliente gañe o concurso de prioridades:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comO dominio de encamiñamento importa tanto como a dirección. Sen el, as consultas de nomes públicos tamén poden enviarse ao resolutor interno, e calquera resolutor interno que rexeite a recursión romperá a navegación mentres deixa a zona privada funcionando. Con el, só os nomes baixo ese sufixo se encamiñan ao resolutor do túnel e todo o demais segue a ligazón física.
Comprobar o resultado: dirección, nome e o camiño exterior
Tres probas separan os fallos posibles. Obtén a dirección privada por IP, logo o mesmo host por nome, logo un sitio público corrente. Unha IP que funciona cun nome que falla apunta ao resolutor; unha IP que falla cun nome que funciona apunta ao encamiñamento; que fallen ambas adoita significar que o túnel non está no camiño.
Despois mira cara a fóra en vez de cara a dentro. A ruta propia do extremo do túnel ten que sobrevivir ao cambio, e calquera bloqueo de fallo debe limitarse ao túnel sen capturar o extremo. Un cliente que segue navegando tras caer o túnel é un problema de política, non de encamiñamento, e non aparecerá en ningunha das tres probas anteriores.
Escribe a lista final na documentación do perfil: as rutas, o resolutor, os dominios e o motivo polo que existe cada un. Unha reconexión que reproduza a mesma táboa é a única proba de que a política local está completa. Se as aplicacións seguen fallando co túnel levantado e as tres probas superadas, o seguinte sitio onde mirar é a clase de problemas de conectado pero fóra de liña, non certificados que xa se verificaron.