route-gateway no és redirect-gateway: què canvia realment
L’opció només proporciona un següent salt per a les rutes que instal·la OpenVPN. Eliminar-la no atura un túnel complet empenyut, i la correcció pertany a la redirecció.
El túnel s’aixeca, la subxarxa privada respon, i la navegació ordinària continua desapareixent dins la VPN tot i que algú ha esborrat la línia de la passarel·la del perfil. Aquesta combinació és l’empremta de la directiva equivocada editada. El que es va eliminar donava al client un següent salt per a les rutes que instal·la; el que continuava capturant trànsit va arribar d’un altre lloc i el va empènyer el servidor. La cobertura i el següent salt són feines separades, i només una decideix si les destinacions públiques utilitzen el túnel.
La línia que heu eliminat era un següent salt, no un commutador de política
Cada ruta que instal·la el client necessita una adreça de passarel·la a la qual apuntar, i la directiva de passarel·la és d’on ve aquesta adreça quan una ruta no n’esmenta cap. Esborreu-la i aquestes rutes no tenen on enganxar-se, així que o no s’instal·len o acaben en un camí que no porta enlloc. La subxarxa privada és exactament el que portava una ruta així.
Mentrestant, el comportament que ha sobreviscut té un altre autor: una opció de redirecció al bloc empenyut, que mou el trànsit sortint ordinari cap al túnel segons les seves banderes. Eliminar la passarel·la no la desactiva ni l’afebleix. El resultat és el pitjor dels dos estats, amb el trànsit públic encara capturat i la destinació privada que justificava el túnel ara inabastable. Per això la segona edició, feta amb el mateix esperit, tampoc no canvia res.
Quatre palanques, quatre feines diferents
En aquesta discussió es citen quatre directius d’intercanviablement, i només una governa la cobertura, és a dir, quines destinacions es dirigeixen pel túnel. Una segona fixa el següent salt que fan servir les rutes, una tercera instal·la un sol prefix, i una quarta llença tot el que ha empenyut el servidor, incloses les rutes privades que necessita el desplegament. La taula les ordena pel que un administrador intenta canviar i no pel nom, perquè són els noms els que causen la confusió. Tracteu-los com quatre decisions separades i trieu la que realment voleu revertir.
A la pràctica, les quatre solen arribar en un sol bloc empenyut, línia rere línia, cosa que les fa semblar parts d’una única configuració. No ho són, i la referència d’OpenVPN les documenta com a mecanismes diferents precisament per això. Esbrinar quina decisió revertiu és la feina; l’edició és una línia.
| 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 |
Filtreu la línia empenyuda, conserveu el següent salt
Si la cobertura que us molesta arriba com a opció empenyuda, la resposta estreta és ignorar aquesta opció pel nom i deixar la resta del bloc empenyut intacta. Escrit com a filtre, sembla la línia de sota, i pertany al perfil del client afectat, no a la configuració del servidor.
pull-filter ignore "redirect-gateway"L’estretor és el punt. Com que el filtre compara un prefix de text, un patró més curt també coincideix amb la directiva del següent salt, cosa que lleva exactament la informació de què depenen les rutes privades i reprodueix l’error original amb un vestit nou. Un filtre també actua només sobre opcions empenyudes, així que no toca mai una línia equivalent escrita localment o imposada per un gestor de xarxa. Torneu a connectar després, perquè una sessió activa no reavalua el que ha empenyut el servidor.
Llegiu la consulta, no la taula
Després de recarregar el perfil, pregunteu al nucli on anirien realment dues destinacions: una dins del prefix privat i una a internet pública. Un bolcat complet de la taula principal és més difícil de llegir i més fàcil de malinterpretar, perquè una ruta pot existir i tot i així perdre contra una coincidència més específica. Amb encaminament per polítiques, la regla, la taula i l’adreça d’origen també formen part de la comprovació.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showLa variant def1 mereix familiaritat, perquè deixa visible l’entrada per defecte antiga mentre un parell de mig-per-defecte guanyen la consulta. Per tant, una línia 0.0.0.0/0 a la sortida no demostra res per si sola. La consulta respon la pregunta que el llistat només sembla respondre.
DNS, IPv6 i la ruta privada encara han de funcionar
Rebutjar una redirecció IPv4 no diu res del resolutor, així que una opció DNS empenyuda pot continuar enviant consultes al túnel mentre les rutes semblen correctes. Un per defecte IPv6 pot fer el mateix per a una família d’adreces que la comprovació IPv4 no ha tocat mai. Tots dos necessiten una decisió explícita en lloc d’una suposició. Després confirmeu que el servei privat encara respon, perquè un túnel dividit que ha perdut la ruta privada no és un túnel dividit, és un de trencat.
Una eina més àmplia mereix un avís: route-nopull descarta totes les rutes empenyudes i totes les opcions DNS empenyudes, cosa que sens dubte atura el túnel complet i igualment sens dubte trenca les rutes privades de què depèn el desplegament, així que és un martell molt més gran que un filtre de noms adreçat a una opció. Comproveu la destinació privada, una destinació pública i el resolutor després de qualsevol canvi, i tracteu una encaixada completada com a prova de res excepte l’encaixada.