Per què una subxarxa encara evita la ruta per defecte de la VPN

Canvieu la VPN a túnel complet, la majoria del trànsit obeeix, i llavors una adreça respon directament — una impressora, un NAS, un host de salt a 10.x. La lectura òbvia és que el túnel té una fuita, així que baixeu la mètrica de la ruta per defecte i no canvia res. Aquest intent fallit és la pista: una ruta per defecte és un recurs de reserva, no un veredicte. La consulta d’encaminament pren el prefix coincident més llarg abans de comparar mai mètriques, així que una /24 continua guanyant a una /0 facis el que facis amb el número que hi adjuntes. Un cop aquest ordre és clar, la fuita sol ser una ruta que algú va instal·lar expressament, o un prefix que el client no pretenia cobrir.

Què promet realment una ruta per defecte

0.0.0.0/0 coincideix amb qualsevol destinació IPv4 amb zero bits d’especificitat. Existeix perquè un host pugui arribar a tot el que la seva taula no descriu millor. Una ruta a 192.168.1.0/24 porta 24 bits coincidents, així que per a 192.168.1.40 guanya abans que ningú compari mètriques, distància administrativa o com anomeni el client el seu camp de prioritat. La mateixa regla val a la FIB de Linux, a la taula d’encaminament de Windows i a la pila BSD darrere de macOS.

En una LAN normal aquest comportament és una característica. La subxarxa local està connectada directament, la impressora continua funcionant mentre el túnel porta la vostra navegació, i res no està mal configurat. La pregunta que val la pena fer no és per què aquella adreça va directa, sinó quin prefix de quina taula hi coincideix, i qui el va posar allà.

Mig-defecte, o per què l’entrada per defecte pot semblar intacta

El redirect-gateway def1 d’OpenVPN és l’exemple més clar. En lloc d’esborrar la vostra ruta per defecte i substituir-la, afegeix 0.0.0.0/1 i 128.0.0.0/1. Junts, el parell cobreix tot l’IPv4, cada prefix és més llarg que /0, i tots dos superen la ruta per defecte del router tot deixant-la al seu lloc. Executeu un llistat de rutes després i la ruta per defecte original encara hi és, encara apunta a la vostra porta d’enllaç; simplement no es tria mai per a destinacions d’internet.

El wg-quick de WireGuard arriba al mateix resultat mitjançant encaminament per política. Amb AllowedIPs cobrint 0.0.0.0/0 crea la seva pròpia taula, hi envia els paquets marcats i afegeix una regla que ignora el prefix de longitud zero de la taula principal. La taula principal conserva la seva entrada per defecte, i les regles decideixen que la taula del túnel es consulta primer per al trànsit que posseeix la interfície.

Els dos dissenys necessiten exactament una ruta fora del túnel: una ruta d’host a l’adreça pròpia del servidor VPN a través de la porta d’enllaç original. Sense ella, el client intentaria portar els paquets que construeixen el túnel dins del túnel, i la connexió no s’acabaria mai. Per tant, una ruta que no és del túnel a la vostra taula és normal fins i tot en un perfil estricte de túnel complet. Les rutes que val la pena qüestionar són les que cobreixen destinacions que realment us importen.

Les mètriques decideixen empats, els prefixos decideixen guanyadors

Les mètriques només es comparen entre candidats que coincideixen igual de bé amb la destinació. A Linux, ip route get 10.20.5.9 imprimeix el guanyador juntament amb la seva taula, i ip route show table all llista els candidats, incloent-hi qualsevol mig-defecte i qualsevol taula a què apunti una regla. A Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 retorna la ruta seleccionada i l’adreça d’origen, mentre que Get-NetRoute mostra la taula crua — però el cost efectiu és la mètrica de la ruta més la mètrica de la interfície, així que un adaptador lent pot perdre un empat que sembla guanyar.

Tres casos cobreixen la major part del que veureu:

• Mateixa destinació, /24 contra /0: la /24 guanya per longitud de prefix, diguin el que diguin les mètriques.
• Mateixa destinació, dues /24 amb mètriques diferents: guanya la mètrica efectiva més baixa.
• Mateixa destinació, dues taules, una triada per una regla de política: la regla tria primer la taula, i la comparació de prefixos passa dins d’ella.

El tercer cas és on acaben la majoria d’aquests informes. Una ip rule de Linux o un filtre de trànsit VPN de Windows pot enviar trànsit a una taula que mai va tenir la ruta per defecte del túnel, i la taula principal sembla perfecta tot el temps.

Qui sol posseir l’evitació

Comenceu pel perfil, no per la taula. Les configuracions de túnel dividit i els paràmetres de VPN per aplicació deixen deliberadament prefixos anomenats fora del túnel; un perfil de feina que protegeix una subxarxa privada i deixa la navegació general anar directa es comporta tal com es va dissenyar, i sobreescriure’l trenca la política que havia de fer complir. La guia d’encaminament VPN de Microsoft traça la mateixa línia entre trànsit forçat pel túnel i excepcions explícites, cosa que la converteix en una comprovació creuada útil abans d’editar res.

A continuació, busqueu restes. Una ruta que apunta a una interfície que ja no existeix, o a una adreça de la xarxa anterior, apareix després que estacions d’acoblament, adaptadors USB i ponts de contenidors vagin i vinguin. Esborrar-la un cop no és el final: els perfils de connexió de NetworkManager, els fitxers netplan i les rutes persistents de Windows la reinstallen a la propera connexió o arrencada, així que trobeu el fitxer o perfil que la posseeix abans d’editar res.

Després comproveu IPv6 per separat. ip -6 route i Get-NetRoute -AddressFamily IPv6 mantenen estat separat, rutes per defecte separades i comportament de client separat. Una auditoria només d’IPv4 no diu res sobre un host de doble pila que prefereix en silenci un camí IPv6 natiu, i això sol pot fer que un client sembli de túnel dividit.

Confirmeu amb el flux real de l’aplicació

Anoteu la destinació que l’aplicació fa servir realment, i després pregunteu al sistema el camí que prendria des de l’adreça d’origen a què s’enllaça aquella aplicació. ip route get 10.20.5.9 from 192.168.1.40 respon això a Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 més l’adreça local ho fa a Windows. Compareu el resultat amb el que afirma el perfil. La pàgina d’IP pública d’un navegador prova una destinació en un protocol i no diu res sobre l’adreça privada que va iniciar la queixa.

Arregleu l’objecte més estret que expliqui la diferència. Si l’excepció està aprovada, anoteu el prefix i deixeu-lo; si no, traieu la ruta o afegiu una ruta explícita més estreta pel túnel en comptes de baixar la mètrica de la ruta per defecte. Baixar una mètrica no pot superar un prefix més llarg, i editar la ruta per defecte mentre dues rutes /1 posseeixen el camí d’internet tampoc no canvia res.

Després reconnecteu el túnel i repetiu la mateixa consulta. Els clients reinstallen les rutes a cada connexió, així que un canvi que només dura fins al següent handshake no s’ha provat. Si el camí encara divergeix, els sospitosos restants són una regla de política, una segona taula o un filtre al costat del client — no la ruta per defecte.

• Anomeneu la destinació i l’adreça d’origen que l’aplicació fa servir realment.
• Mostreu la ruta guanyadora amb ip route get o Find-NetRoute.
• Comproveu si un parell /1 o una taula de política posseeix el camí d’internet.
• Llisteu cada prefix més llarg que /0 que coincideixi amb la destinació.
• Repetiu la comprovació d’IPv6 per separat.
• Resseguiu la ruta que sobreviu fins al fitxer, perfil o filtre que la instal·la.
• Reconnecteu i torneu a executar la consulta abans de donar-ho per arreglat.

Si tots set coincideixen amb el perfil, el túnel fa exactament el que estava configurat per fer, i l’arranjament pertany al perfil i no a una mètrica.