Per què una VPN de túnel complet amaga les teves VLAN locals encaminades

L'interruptor “allow local network” d'un client VPN sona com si cobrís tot el que hi ha a l'edifici. A la pràctica, normalment afegeix unes quantes excepcions d'adreces privades a la ruta per defecte del túnel i s'hi atura. La teva VLAN d'emmagatzematge només continua sent accessible si una ruta per a aquest prefix concret sobreviu a l'arribada del túnel, i en molts clients no hi sobreviu.

Això és una qüestió d'encaminament i no un paràmetre de la VPN, cosa que és una bona notícia: té una resposta concreta.

Què cobreix realment allow-local-network

Els clients implementen aquesta opció de maneres diferents. Alguns afegeixen rutes per a la subxarxa a què està connectada la màquina, alguns afegeixen els rangs RFC 1918, i uns pocs només exclouen el gateway per defecte. Cap d'ells no sap que el router de l'oficina també serveix una VLAN d'emmagatzematge, un segment de laboratori o una subxarxa d'impressores, perquè aquests prefixos no són al cable que el client pot veure. Llegeix la documentació del propi client per al comportament exacte en lloc de suposar que l'etiqueta descriu la teva topologia.

La distinció importa sobretot en un disseny de túnel complet, on el client substitueix deliberadament la ruta per defecte perquè tot el trànsit passi per la VPN. Aquest és el sentit de tot el disseny, i també és el que fa desaparèixer les xarxes locals encaminades. Mai no estaven cobertes per una ruta pròpia; anaven muntades sobre la ruta per defecte que s'acaba de substituir. Un client no pot encaminar allò que no sap que existeix, i només aprèn els prefixos adjunts a la seva pròpia interfície. Tota la resta l'ha de descriure algú que conegui la topologia.

Les rutes connectades s'aturen al primer router

Una estació de treball a 192.168.10.20/24 amb gateway 192.168.10.1 obté automàticament una ruta connectada per a 192.168.10.0/24. La VLAN d'emmagatzematge a 192.168.20.0/24 és un prefix diferent, accessible només a través d'aquest gateway, i l'estació de treball no té cap ruta per a ella més enllà de la per defecte. Abans que pugi el túnel, la ruta per defecte ordinària envia per casualitat el trànsit d'emmagatzematge a 192.168.10.1 i tot funciona.

Quan la VPN instal·la una ruta per defecte de túnel complet, els paquets per a 192.168.20.1 segueixen la nova ruta per defecte cap al túnel. El gateway remot no té ni idea d'on viu aquest prefix, així que els descarta o els reenvia a un lloc inútil. No hi havia res mal configurat a la VLAN d'emmagatzematge; el seu camí era prestat, i el préstec s'ha reclamat.

La temptació és recórrer a una excepció àmplia, com ara una parella de rutes /1 o una segona ruta per defecte. Resisteix-la. Com més estreta és l'excepció, més fàcil és explicar-la, auditar-la i eliminar-la quan la xarxa canvia.

Posa l'excepció a la taula que guanya

Dins d'una sola taula d'encaminament, una /24 guanya una /0 o una /1 per coincidència de prefix més llarg, així que una ruta específica cap a la VLAN d'emmagatzematge a través del gateway local és suficient, sempre que la taula es consulti. A Linux la forma habitual és curta:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

L'encaminament per polítiques complica aquesta garantia. Una regla anterior pot enviar el trànsit a una taula la pròpia ruta per defecte de la qual apunta cap al túnel, i aleshores la taula principal que conté la teva /24 no s'assoleix mai. Revisa les regles abans de donar per fet que la ruta és autoritativa, perquè una entrada que sembla correcta a la taula equivocada explica una fallada que sembla una ruta trencada.

Després fes que l'entrada sigui persistent mitjançant el mecanisme que admeti el client o el gestor de xarxa que posseeix la interfície. Una ruta escrita al prompt desapareix a la propera reconnexió, i una ruta lligada a un sol gateway Wi-Fi no és portable a la xarxa següent que visiti l'ordinador portàtil.

Els noms i les polítiques no segueixen les rutes

Arreglar la ruta restaura els paquets, no els noms. Si els dispositius locals es resolen mitjançant un resolutor empès que no en sap res, el muntatge continua fallant encara que l'adreça sigui abastable. Els noms locals necessiten un arranjament local o de DNS dividit, i això és una decisió separada de l'excepció de ruta.

La política torna a ser una altra cosa. El filtre d'accés local d'un client VPN pot prohibir deliberadament el trànsit cap a rangs privats, i una ruta no anul·la aquesta regla. En una xarxa no confiable, una adreça privada tampoc no és prova que la destinació sigui el teu servidor d'emmagatzematge, així que l'excepció ha de ser tan específica com la ruta mateixa.

Un contracte que pots lliurar

El disseny acabat hauria de llegir-se com una llista curta: el trànsit general d'internet segueix el túnel, i aquests prefixos locals amb nom conserven el seu camí a través del router local. Anota els prefixos, el següent salt i el sufix DNS que hi va associat, i mantingues la llista prou curta perquè algú la pugui verificar sense llegir una taula d'encaminament.

Compte amb el solapament entre rangs locals i remots. Una VLAN d'emmagatzematge que comparteix prefix amb alguna cosa darrere de la VPN es resoldrà a la ruta que sigui més específica, i el comportament resultant és confús d'una manera que sembla intermitent. Renumerar un costat sol ser més barat que depurar l'ambigüitat per sempre.

Prova el contracte dues vegades: una amb el túnel aixecat i una amb el túnel baixat. Si el camí local només funciona en un d'aquests estats, l'excepció encara no és un contracte.