O pull-filter de OpenVPN coincide con máis que a ruta que querías

Engades unha liña para conservar a túa ruta predeterminada local, e despois o túnel xa non chega ao servidor DNS interno. A liña era pull-filter ignore "route", que non significa "ignora esta ruta". Significa "descarta calquera opción enviada cuxo texto comece por esas cinco letras", e nun servidor normal iso inclúe route-gateway, route-metric e route-ipv6 xunto coas propias rutas. A lista de comprobación de abaixo é o que repaso antes de tocar un perfil que ten que usar outra persoa.

O filtro só se aplica ás opcións enviadas

pull-filter actúa sobre as liñas de opción que o servidor envía unha vez establecido o túnel, e sobre nada máis. As opcións escritas no teu ficheiro local non se ven afectadas, nin tampouco o tráfico das aplicacións. Se esperabas impedir que un proceso usase o túnel, esta é a ferramenta completamente equivocada e ningunha combinación de filtros o logrará.

Ese alcance é útil, porque significa que podes deixar a configuración do servidor tranquila e aínda así rexeitar parte dela localmente. Tamén é un límite que convén deixar escrito no tícket: un filtro cambia o que acepta este cliente, non o que ofrece o servidor. Non ten efecto sobre outros usuarios do mesmo perfil. Tampouco sobrevive a un cambio a outro cliente que non implemente a opción, algo que convén saber antes de construír un fluxo de traballo sobre ela.

Confirma que envía realmente o servidor antes de escribir o patrón. Con alta verbosidade o cliente imprime a cadea de opcións enviadas que recibiu, e esa é a única fonte honesta para o texto exacto co que comparas:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Le a liña enviada como unha lista de opcións separadas por comas, e fíxate en que os nomes de opción e os seus argumentos sepáranse con espazos. O teu texto de filtro compárase con ese fluxo, por iso os espazos importan tanto no paso seguinte.

A coincidencia é un prefixo, así que os espazos son todo

A comparación é un prefixo de cadea, non un nome de opción analizado. Por iso "route" coincide con route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 e route-metric 100. Un espazo final estreitao á familia que probablemente querías, e o prefixo completo estreitao aínda máis a un destino concreto.

A última fila é a que atrapa a xente durante o traballo con túnel dividido. Conservar o teu propio resolutor é unha opción lexítima, e significa que cada nome interno depende agora dun resolutor que non pode ver a zona privada. É unha consecuencia que se acepta a propósito, non un efecto secundario que se descobre en produción.

A coincidencia por prefixo tamén significa que unha regra pode ampliarse máis tarde en silencio. Cando o servidor engade unha opción nova que comeza polo teu texto, o teu filtro comeza a aplicarse a ela sen que ninguén edite o teu perfil. Ese é o modo de fallo contra o que hai que deseñar, e a mitigación é coincidir con tanta parte da opción como poidas, non con tan pouca como poidas.

Tres verbos con tres resultados distintos

accept, ignore e reject non son tres grafías da mesma idea. Difieren en que fai o cliente cunha coincidencia e en se alguén se entera.

ignore descarta a opción coincidente en silencio, que é o que queres para un axuste que substituíches deliberadamente. reject descártaa e fai que o cliente se queixe, que é o que queres cando a súa ausencia debe verse nun rexistro en lugar de descubrirse máis tarde. accept é a forma positiva, úsase cando constrúes unha lista de permitidos en vez de quitar opcións individuais.

Sexa cal sexa o verbo que uses, os filtros aplícanse na orde en que aparecen, así que dúas regras solapadas producen un resultado dependente da orde e moi difícil de revisar. Ten unha regra por intención e pon o texto máis específico en cada unha. Se necesitas unha lista de permitidos, prefire unhas poucas regras accept a un montón de regras ignore que suman o mesmo. Así os revisores poden ler o ficheiro de arriba abaixo e predicir o resultado, e esa é a única proba que escala.

Comproba a ruta e o resolutor aplicados, non o perfil

Un filtro que parece correcto no ficheiro aínda pode deixarte cun túnel que non encamiña nada útil. Verifica o efecto no sistema en marcha, onde as opcións enviadas xa se aplicaron ou descartaron:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

As dúas primeiras liñas dinche se chegou a ruta predeterminada enviada e cantas entradas estáticas sobreviviron. A consulta ao resolutor mostra que servidor usa realmente a interface do túnel, e é normalmente onde aparece unha sorpresa de DNS. A última liña responde á única pregunta que lle importa a un usuario.

Proba as dúas direccións mentres esteas aí. Unha regra que mantén o teu internet local funcionando pero rompe en silencio a resolución de nomes interna pasa unha comprobación superficial e falla a primeira tarefa real, así que inclúe un recurso interno e un sitio público na mesma proba.

Rexistra a excepción e quen é o seu responsable

Un filtro é unha excepción ao deseño do operador, así que déixao escrito cun motivo e un punto de revisión. "Ignora as rutas enviadas para conservar a predeterminada local" é revisable; unha liña espida nun perfil non o é, e a seguinte persoa borraraa ou ampliaraa a cegas.

A versión tamén conta aquí. O comportamento de coincidencia e a sintaxe aceptada exacta refináronse ao longo de OpenVPN 2.4, 2.5 e 2.6, así que confirma o patrón co manual da compilación que distribúes e non cunha mensaxe de foro sobre unha versión máis antiga. O manual de OpenVPN 2.6 documenta a opción e a súa regra de coincidencia.

Por último, acorda a excepción con quen xestiona o servidor. Un filtro do lado do cliente que contradí unha política deliberada do servidor é un incidente de soporte esperando a próxima auditoría, e é moito máis barato resolvelo antes de que o perfil saia que despois de que alguén note que faltan as rutas.