route-gateway no es redirect-gateway: qué cambia en realidad
La opción solo aporta un siguiente salto a las rutas que instala OpenVPN. Eliminarla no apaga un túnel completo empujado, y la corrección pertenece a la redirección.
Tu túnel se levanta, la subred privada responde y la navegación normal sigue desapareciendo dentro de la VPN aunque alguien haya borrado la línea de la puerta de enlace del perfil. Esa combinación es la huella de la directiva equivocada que se editó. Lo que se eliminó daba al cliente un siguiente salto para las rutas que instala; lo que siguió capturando tráfico llegó de otro sitio y lo empujó el servidor. La cobertura y el siguiente salto son tareas separadas, y solo una decide si los destinos públicos usan el túnel.
La línea que eliminó era un siguiente salto, no un interruptor de política
Cada ruta que instala el cliente necesita una dirección de puerta de enlace a la que apuntar, y la directiva de puerta de enlace es de donde viene esa dirección cuando una ruta no nombra ninguna. Bórrala y esas rutas no tienen dónde engancharse, así que o no se instalan o acaban en un camino que no lleva a ninguna parte. La subred privada es exactamente lo que transportaba una ruta así.
Mientras tanto, el comportamiento que sobrevivió tiene otro autor: una opción de redirección en el bloque empujado, que mueve el tráfico saliente normal al túnel según sus banderas. Eliminar la puerta de enlace ni la desactiva ni la debilita. El resultado es lo peor de ambos estados, con el tráfico público aún capturado y el destino privado que justificaba el túnel ahora inalcanzable. Por eso la segunda edición, hecha con el mismo espíritu, tampoco cambia nada.
Cuatro palancas, cuatro tareas distintas
Cuatro directivas se citan de forma intercambiable en esta discusión, y solo una de ellas gobierna la cobertura, es decir, qué destinos se enrutan por el túnel. Una segunda fija el siguiente salto que usan las rutas, una tercera instala un solo prefijo y una cuarta descarta todo lo que empujó el servidor, incluidas las rutas privadas que necesita el despliegue. La tabla las ordena por lo que un administrador intenta cambiar y no por el nombre, porque son los nombres los que causan la confusión. Trátelas como cuatro decisiones separadas y elija la que realmente quiera revertir.
En la práctica las cuatro suelen llegar en un mismo bloque empujado, línea tras línea, lo que las hace parecer partes de una sola configuración. No lo son, y la referencia de OpenVPN las documenta como mecanismos distintos precisamente por eso. Averiguar qué decisión está revirtiendo es la tarea; la edición es una línea.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filtre la línea empujada, conserve el siguiente salto
Si la cobertura que le molesta llega como opción empujada, la respuesta estrecha es ignorar esa opción por su nombre y dejar intacto el resto del bloque empujado. Escrito como filtro, se parece a la línea de abajo, y pertenece al perfil del cliente afectado, no a la configuración del servidor.
pull-filter ignore "redirect-gateway"Lo estrecho es el punto. Como el filtro compara un prefijo de texto, un patrón más corto también coincide con la directiva del siguiente salto, lo que arranca justo la información de la que dependen las rutas privadas y reproduce el error original con un disfraz nuevo. Un filtro también actúa solo sobre opciones empujadas, así que nunca toca una línea equivalente escrita localmente o impuesta por un gestor de red. Vuelva a conectarse después, porque una sesión activa no reevalúa lo que empujó el servidor.
Lea la consulta, no la tabla
Tras recargar el perfil, pregunte al núcleo adónde irían realmente dos destinos: uno dentro del prefijo privado y otro en la internet pública. Un volcado completo de la tabla principal es más difícil de leer y más fácil de malinterpretar, porque una ruta puede existir y aun así perder frente a una coincidencia más específica. Con enrutamiento por políticas, la regla, la tabla y la dirección de origen también forman parte de la comprobación.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showLa variante def1 merece familiaridad, porque deja visible la entrada por defecto antigua mientras un par de medias por defecto ganan la consulta. Por tanto, una línea 0.0.0.0/0 en la salida no demuestra nada por sí sola. La consulta responde la pregunta que el listado solo parece responder.
DNS, IPv6 y la ruta privada aún tienen que funcionar
Rechazar una redirección IPv4 no dice nada del resolutor, así que una opción DNS empujada puede seguir enviando consultas al túnel mientras las rutas parecen correctas. Un por defecto IPv6 puede hacer lo mismo para una familia de direcciones que la comprobación IPv4 nunca tocó. Ambos necesitan una decisión explícita en lugar de una suposición. Luego confirme que el servicio privado sigue respondiendo, porque un túnel dividido que ha perdido su ruta privada no es un túnel dividido, es uno roto.
Una herramienta más amplia merece un aviso: route-nopull descarta todas las rutas empujadas y todas las opciones DNS empujadas, lo que sin duda detiene el túnel completo e igual de sin duda rompe las rutas privadas de las que depende el despliegue, así que es un martillo mucho mayor que un filtro de nombres dirigido a una opción. Compruebe el destino privado, un destino público y el resolutor tras cualquier cambio, y trate un apretón de manos completado como prueba de nada excepto del apretón.