Perché una VPN a tunnel completo nasconde le tue VLAN locali instradate

L'interruttore «allow local network» in un client VPN sembra coprire tutto ciò che c'è nell'edificio. In pratica di solito aggiunge qualche eccezione di indirizzi privati alla rotta predefinita del tunnel e si ferma lì. La tua VLAN di archiviazione resta raggiungibile solo se una rotta per quel prefisso specifico sopravvive all'arrivo del tunnel, e su molti client non succede.

È una questione di routing e non un'impostazione della VPN, il che è una buona notizia: ha una risposta concreta.

Che cosa copre davvero allow-local-network

I client implementano quell'opzione in modo diverso. Alcuni aggiungono rotte per la sottorete a cui è collegata la macchina, altri aggiungono gli intervalli RFC 1918, e pochi escludono solo il gateway predefinito. Nessuno di loro sa che il router dell'ufficio serve anche una VLAN di archiviazione, un segmento di laboratorio o una sottorete di stampanti, perché quei prefissi non sono sul cavo che il client vede. Leggi la documentazione del client stesso per il comportamento esatto invece di presumere che l'etichetta descriva la tua topologia.

La distinzione conta soprattutto in un progetto a tunnel completo, dove il client sostituisce deliberatamente la rotta predefinita affinché tutto il traffico passi dalla VPN. È l'intero scopo del progetto, ed è anche ciò che fa sparire le reti locali instradate. Non erano mai coperte da una rotta propria; viaggiavano sulla rotta predefinita appena sostituita. Un client non può instradare ciò che non sa esistere, e impara solo i prefissi collegati alla propria interfaccia. Tutto il resto deve essere descritto da qualcuno che conosce la topologia.

Le rotte connesse si fermano al primo router

Una workstation su 192.168.10.20/24 con gateway 192.168.10.1 ottiene automaticamente una rotta connessa per 192.168.10.0/24. La VLAN di archiviazione su 192.168.20.0/24 è un altro prefisso, raggiungibile solo attraverso quel gateway, e la workstation non ha alcuna rotta per essa oltre a quella predefinita. Prima che il tunnel salga, la rotta predefinita ordinaria manda per caso il traffico di archiviazione a 192.168.10.1 e tutto funziona.

Quando la VPN installa una rotta predefinita a tunnel completo, i pacchetti per 192.168.20.1 seguono la nuova rotta predefinita dentro il tunnel. Il gateway remoto non ha idea di dove viva quel prefisso, quindi li scarta o li inoltra in un posto inutile. Nulla era configurato male sulla VLAN di archiviazione; il suo percorso era in prestito, e il prestito è stato richiamato.

La tentazione è ricorrere a un'eccezione ampia, come una coppia di rotte /1 o una seconda rotta predefinita. Resistila. Più l'eccezione è stretta, più è facile spiegarla, verificarla e rimuoverla quando la rete cambia.

Metti l'eccezione nella tabella che vince

All'interno di una tabella di routing, una /24 batte una /0 o una /1 per corrispondenza del prefisso più lungo, quindi una rotta specifica verso la VLAN di archiviazione attraverso il gateway locale basta, purché la tabella venga consultata. Su Linux la forma abituale è breve:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Il routing per policy complica questa garanzia. Una regola precedente può mandare il traffico a una tabella la cui rotta predefinita punta dentro il tunnel, e la tabella principale che contiene la tua /24 non viene mai raggiunta. Controlla le regole prima di dare per scontato che la rotta faccia fede, perché una voce dall'aspetto corretto nella tabella sbagliata spiega un guasto che sembra una rotta rotta.

Poi rendi la voce persistente tramite il meccanismo supportato dal client o il gestore di rete che possiede l'interfaccia. Una rotta digitata al prompt sparisce alla riconnessione successiva, e una rotta legata a un solo gateway Wi-Fi non è trasferibile alla rete successiva che il portatile visita.

I nomi e le policy non seguono le rotte

Riparare la rotta ripristina i pacchetti, non i nomi. Se i dispositivi locali vengono risolti tramite un resolver imposto che non sa nulla di loro, il mount fallisce comunque anche se l'indirizzo è raggiungibile. I nomi locali richiedono un assetto DNS locale o diviso, e questa è una decisione separata dall'eccezione di rotta.

La policy è di nuovo un'altra cosa. Il filtro di accesso locale di un client VPN può vietare deliberatamente il traffico verso intervalli privati, e una rotta non aggira quella regola. Su una rete non affidabile, un indirizzo privato non è nemmeno prova che la destinazione sia il tuo server di archiviazione, quindi l'eccezione dovrebbe essere specifica quanto la rotta stessa.

Un contratto che puoi consegnare

Il progetto finito dovrebbe leggersi come una lista breve: il traffico internet generale segue il tunnel, e questi prefissi locali con nome mantengono il loro percorso attraverso il router locale. Annota i prefissi, il prossimo hop e il suffisso DNS che li accompagna, e tieni la lista abbastanza corta che qualcuno possa verificarla senza leggere una tabella di routing.

Occhio alla sovrapposizione tra intervalli locali e remoti. Una VLAN di archiviazione che condivide un prefisso con qualcosa dietro la VPN verrà risolta verso la rotta più specifica, e il comportamento risultante è confuso in un modo che sembra intermittente. Rinumerare un lato di solito costa meno che fare debug dell'ambiguità per sempre.

Prova il contratto due volte: una con il tunnel attivo e una con il tunnel abbassato. Se il percorso locale funziona solo in uno di questi stati, l'eccezione non è ancora un contratto.