route-gateway non é redirect-gateway: que cambia realmente
A opción só fornece un seguinte salto ás rutas que instala OpenVPN. Eliminala non apaga un túnel completo empurrado, e a corrección pertence á redirección.
O teu túnel levanta, a subrede privada responde, e a navegación normal segue desaparecendo dentro da VPN aínda que alguén borrou a liña da pasarela do perfil. Esa combinación é a pegada da directiva incorrecta que se editou. O que se eliminou daba ao cliente un seguinte salto para as rutas que instala; o que seguiu capturando tráfico chegou doutro sitio e empurrouno o servidor. A cobertura e o seguinte salto son tarefas separadas, e só unha decide se os destinos públicos usan o túnel.
A liña que eliminaches era un seguinte salto, non un interruptor de política
Cada ruta que instala o cliente necesita un enderezo de pasarela ao que apuntar, e a directiva de pasarela é de onde vén ese enderezo cando unha ruta non nomea ningún. Bórraa e esas rutas non teñen onde engancharse, así que ou non se instalan ou acaban nun camiño que non leva a ningures. A subrede privada é exactamente o que transportaba unha ruta así.
Mentres tanto, o comportamento que sobreviviu ten outro autor: unha opción de redirección no bloque empurrado, que move o tráfico saínte normal ao túnel segundo as súas bandeiras. Eliminar a pasarela nin a desactiva nin a debilita. O resultado é o peor de ambos estados, co tráfico público aínda capturado e o destino privado que xustificaba o túnel agora inalcanzable. Por iso a segunda edición, feita co mesmo espírito, tampouco cambia nada.
Catro panca, catro tarefas distintas
Catro directivas cítense de forma intercambiable nesta discusión, e só unha delas goberna a cobertura, é dicir, que destinos se encamiñan polo túnel. Unha segunda fixa o seguinte salto que usan as rutas, unha terceira instala un só prefixo, e unha cuarta descarta todo o que empurrou o servidor, incluídas as rutas privadas que necesita o despregamento. A táboa ordénaas polo que un administrador intenta cambiar e non polo nome, porque son os nomes os que causan a confusión. Trátaas como catro decisións separadas e escolle a que realmente queres revogar.
Na práctica as catro adoitan chegar nun mesmo bloque empurrado, liña tras liña, o que as fai parecer partes dunha única configuración. Non o son, e a referencia de OpenVPN documéntaas como mecanismos distintos precisamente por iso. Avariguar que decisión estás revogando é a tarefa; a edición é unha liña.
| 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 |
Filtra a liña empurrada, conserva o seguinte salto
Se a cobertura que che molesta chega como opción empurrada, a resposta estreita é ignorar esa opción polo seu nome e deixar intacto o resto do bloque empurrado. Escrito como filtro, parece a liña de abaixo, e pertence ao perfil do cliente afectado, non á configuración do servidor.
pull-filter ignore "redirect-gateway"O estreito é o punto. Como o filtro compara un prefixo de texto, un patrón máis curto tamén coincide coa directiva do seguinte salto, o que arrinca xusto a información da que dependen as rutas privadas e reproduce o erro orixinal cun disfrace novo. Un filtro tamén actúa só sobre opcións empurradas, así que nunca toca unha liña equivalente escrita localmente ou imposta por un xestor de rede. Vólve conectar despois, porque unha sesión activa non reavaliá o que empurrou o servidor.
Le a consulta, non a táboa
Despois de recargar o perfil, pregúntalle ao núcleo a onde irían realmente dous destinos: un dentro do prefixo privado e outro na internet pública. Un volcado completo da táboa principal é máis difícil de ler e máis fácil de malinterpretar, porque unha ruta pode existir e aínda así perder fronte a unha coincidencia máis específica. Con encamiñamento por políticas, a regra, a táboa e o enderezo de orixe tamén forman parte da comprobación.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showA variante def1 merece familiaridade, porque deixa visible a entrada por defecto antiga mentres un par de medias por defecto gañan a consulta. Por tanto, unha liña 0.0.0.0/0 na saída non demostra nada por si soa. A consulta responde a pregunta que o listado só parece responder.
DNS, IPv6 e a ruta privada aínda teñen que funcionar
Rexeitar unha redirección IPv4 non di nada do resolutor, así que unha opción DNS empurrada pode seguir enviando consultas ao túnel mentres as rutas parecen correctas. Un por defecto IPv6 pode facer o mesmo para unha familia de enderezos que a comprobación IPv4 nunca tocou. Ambos necesitan unha decisión explícita en lugar dunha suposición. Despois confirma que o servizo privado segue respondendo, porque un túnel dividido que perdeu a súa ruta privada non é un túnel dividido, é un roto.
Unha ferramenta máis ampla merece un aviso: route-nopull descarta todas as rutas empurradas e todas as opcións DNS empurradas, o que sen dúbida detén o túnel completo e igual de sen dúbida rompe as rutas privadas das que depende o despregamento, así que é un martelo moito maior que un filtro de nomes dirixido a unha opción. Comproba o destino privado, un destino público e o resolutor tras calquera cambio, e trata un aperto de mans completado como proba de nada excepto do aperto.