Por que unha VPN de túnel completo agocha as túas VLAN locais encamiñadas

O interruptor “allow local network” dun cliente VPN soa como se cubrise todo o que hai no edificio. Na práctica adoita engadir unhas cantas excepcións de enderezos privados á ruta predeterminada do túnel e deterse aí. A túa VLAN de almacenamento só segue sendo accesible se unha ruta para ese prefixo concreto sobrevive á chegada do túnel, e en moitos clientes non o fai.

É unha cuestión de encamiñamento e non un axuste da VPN, o cal é unha boa noticia: ten unha resposta concreta.

Que cubre realmente allow-local-network

Os clientes implementan esa opción de forma distinta. Algúns engaden rutas para a subrede á que está conectada a máquina, outros engaden os rangos RFC 1918 e uns poucos só exclúen a pasarela predeterminada. Ningún sabe que o router da túa oficina tamén serve unha VLAN de almacenamento, un segmento de laboratorio ou unha subrede de impresoras, porque eses prefixos non están no cable que o cliente pode ver. Le a documentación do propio cliente para o comportamento exacto en lugar de supor que a etiqueta describe a túa topoloxía.

A distinción importa sobre todo nun deseño de túnel completo, onde o cliente substitúe deliberadamente a ruta predeterminada para que todo o tráfico pase pola VPN. Ese é o obxectivo de todo o deseño, e tamén é o que fai desaparecer as redes locais encamiñadas. Nunca estiveron cubertas por unha ruta propia; ían montadas sobre a ruta predeterminada que acaba de ser substituída. Un cliente non pode encamiñar o que non sabe que existe, e só aprende os prefixos conectados á súa propia interface. Todo o demais ten que describilo alguén que coñeza a topoloxía.

As rutas conectadas detéñense no primeiro router

Unha estación de traballo en 192.168.10.20/24 con pasarela 192.168.10.1 obtén automaticamente unha ruta conectada para 192.168.10.0/24. A VLAN de almacenamento en 192.168.20.0/24 é un prefixo distinto, accesible só a través desa pasarela, e a estación non ten ningunha ruta para ela máis alá da predeterminada. Antes de que suba o túnel, a ruta predeterminada ordinaria envía por casualidade o tráfico de almacenamento a 192.168.10.1 e todo funciona.

Cando a VPN instala unha ruta predeterminada de túnel completo, os paquetes para 192.168.20.1 seguen a nova ruta predeterminada cara ao túnel. A pasarela remota non ten nin idea de onde vive ese prefixo, así que os descarta ou os reenvía a un lugar inútil. Nada estaba mal configurado na VLAN de almacenamento; o seu camiño era prestado, e o préstamo foi reclamado.

A tentación é recorrer a unha excepción ampla, como un par de rutas /1 ou unha segunda ruta predeterminada. Resístete. Canto máis estreita é a excepción, máis fácil resulta explicala, auditarla e eliminala cando a rede cambia.

Pon a excepción na táboa que gaña

Dentro dunha soa táboa de encamiñamento, unha /24 vence unha /0 ou unha /1 pola coincidencia de prefixo máis longa, así que unha ruta concreta cara á VLAN de almacenamento pola pasarela local abonda, sempre que a táboa se consulte. En Linux a forma habitual é breve:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

O encamiñamento por políticas complica esa garantía. Unha regra anterior pode enviar o tráfico a unha táboa cuxa propia ruta predeterminada apunta cara ao túnel, e entón a táboa principal que contén o teu /24 nunca se alcanza. Revisa as regras antes de dar por feito que a ruta é autoritativa, porque unha entrada que parece correcta na táboa equivocada explica un fallo que parece unha ruta rota.

Despois fai que a entrada sexa persistente mediante o mecanismo que admita o cliente ou o xestor de rede que posúe a interface. Unha ruta escrita no indicador desaparece na seguinte reconexión, e unha ruta atada a unha soa pasarela Wi-Fi non é portable á seguinte rede que visite o portátil.

Os nomes e as políticas non seguen as rutas

Arranxar a ruta restaura os paquetes, non os nomes. Se os dispositivos locais se resolven mediante un resolvedor imposto que non sabe nada deles, a montaxe segue fallando aínda que o enderezo sexa alcanzable. Os nomes locais necesitan un arranxo local ou de DNS dividido, e esa é unha decisión separada da excepción de ruta.

A política volve ser outra cousa. O filtro de acceso local dun cliente VPN pode prohibir deliberadamente o tráfico cara a rangos privados, e unha ruta non anula esa regra. Nunha rede non fiable, un enderezo privado tampouco é proba de que o destino sexa o teu servidor de almacenamento, así que a excepción debería ser tan concreta como a propia ruta.

Un contrato que podes entregar

O deseño terminado debería lerse como unha lista curta: o tráfico xeral de internet segue o túnel, e estes prefixos locais con nome conservan o seu camiño polo router local. Anota os prefixos, o seguinte salto e o sufixo DNS que vai con eles, e mantén a lista o bastante curta para que alguén poida verificála sen ler unha táboa de encamiñamento.

Ollo co solapamento entre rangos locais e remotos. Unha VLAN de almacenamento que comparte prefixo con algo detrás da VPN resolverase á ruta que sexa máis específica, e o comportamento resultante é confuso dunha forma que parece intermitente. Renumerar un lado adoita ser máis barato que depurar a ambigüidade para sempre.

Proba o contrato dúas veces: unha co túnel levantado e outra con el baixado. Se o camiño local só funciona nun deses estados, a excepción aínda non é un contrato.