Due siti hanno bisogno degli stessi VLAN ID per una VPN di sito?

Gli stessi numeri VLAN in due uffici sembrano dover aiutare un tunnel tra siti, e non cambiano nulla di ciò che il tunnel trasporta. Un VLAN ID etichetta un dominio di broadcast Ethernet all’interno di un edificio; il tunnel inoltra i pacchetti IP tra i gateway. Due siti possono usare una numerazione VLAN completamente diversa e comunque instradarsi l’uno verso l’altro, e due siti possono usare la stessa numerazione VLAN e comunque non raggiungersi. La variabile che decide la raggiungibilità è il piano degli indirizzi.

Il mito: gli stessi VLAN ID alle due estremità

La convinzione viene da un luogo ragionevole. Dentro un edificio, due porte nello stesso VLAN possono parlarsi e due porte in VLAN diversi no, quindi il numero VLAN sembra ciò che concede la connettività. Attraverso un tunnel instradato non c’è alcun segmento Ethernet condiviso che l’etichetta possa descrivere, e i gateway non si scambiano mai etichette VLAN.

Ciò di cui il tunnel ha bisogno è una coppia di ambiti di indirizzi che non si sovrappongono e una politica che consenta il traffico tra loro. Cambiate il VLAN in qualsiasi ufficio e il tunnel continua a funzionare, perché nulla nella configurazione del tunnel lo referenziava. È il test che risolve la discussione: rinumerate un VLAN, lasciate gli indirizzi intatti e osservate se il tunnel resta attivo.

Il test inverso è altrettanto istruttivo. Date ai due uffici la stessa sottorete e nessuna quantità di numeri VLAN coincidenti renderà un indirizzo non ambiguo.

Che cosa trasporta realmente il tunnel

IPsec protegge i pacchetti IP secondo una politica espressa in indirizzi, protocolli e porte. L’architettura IPsec descrive quei selettori a livello IP, che è diversi livelli sopra qualunque cosa descriva un’etichetta di switch. Quando un pacchetto entra nel tunnel ha già lasciato il VLAN; l’etichetta è stata consumata dallo switch locale.

I progetti basati su politica e quelli basati su rotte differiscono nel modo in cui scelgono il tunnel, non in ciò che possono trasportare. Un peer basato su politica confronta i selettori di traffico e invia i pacchetti corrispondenti nel tunnel. Un peer basato su rotte instrada il traffico su un’interfaccia di tunnel e lascia decidere la tabella di routing. Entrambi negoziano ancora un ambito di protezione, quindi una rotta che punta al tunnel non amplia ciò che i peer hanno accettato di proteggere.

Questa distinzione spiega un mezzo fallimento comune: la rotta esiste, i pacchetti entrano nel tunnel e il lato remoto li scarta perché i selettori negoziati non hanno mai incluso quel prefisso. Leggere le politiche installate mostra quale ambito è realmente entrato in vigore.

ip xfrm policy
ip route show
swanctl --list-sas

La sovrapposizione che rompe davvero

Due uffici con sottoreti distinte si instradano pulitamente attraverso un tunnel, e i loro numeri VLAN sono irrilevanti. Due uffici con la stessa sottorete no, perché una richiesta per un dato indirizzo ha due significati possibili e la tabella di routing può sceglierne solo uno. Rinumerare un sito è la soluzione pulita, ed è di solito più economica delle alternative una volta contati i cambi DNS e firewall.

Quando la rinumerazione è impossibile, un progetto di traduzione deliberato può presentare viste di indirizzi distinte a ciascun lato. Ciò significa mappatura uno a uno, selettori corrispondenti, voci DNS che riflettono la vista tradotta e routing di ritorno che sopravvive alla riscrittura. È un progetto supportato con un costo operativo reale, e non è ciò che fa cambiare un VLAN ID.

Gli stessi numeri VLAN alle due estremità sono talvolta una coincidenza di un modello condiviso, e trattare quella coincidenza come la causa di un tunnel funzionante porta al cambiamento sbagliato quando qualcosa si rompe più avanti.

Un compito per livello, messo per iscritto

Lo switch locale decide quali porte condividono un dominio di broadcast, e la sua numerazione VLAN è una contabilità locale che nessun altro sito deve conoscere. Il gateway autentica il peer e applica l’ambito di protezione negoziato. La tabella di routing decide dove va dopo un pacchetto decifrato, e la politica di accesso decide se quel pacchetto avrebbe dovuto essere consentito.

Tenere separati questi compiti è ciò che rende sicuri i cambiamenti. Una rinumerazione VLAN in un ufficio tocca lo switch locale, l’ambito DHCP e forse una zona firewall, e non tocca il tunnel. Un cambio di prefisso tocca i selettori del tunnel, le rotte su entrambi i lati e la politica di accesso, e non tocca le etichette dello switch.

Le rotte di ritorno, il DNS privato e i requisiti di identità delle applicazioni sono di nuovo compiti separati, e nessuno di essi arriva copiando un numero VLAN dall’altro sito. Un documento di progetto che elenca i prefissi raggiungibili e i servizi consentiti sopravvive a un rinnovo dello switch; uno che elenca numeri VLAN no.

Confermate l’immagine locale con gli strumenti bridge prima di supporre che un’etichetta raggiunga il tunnel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Quando l’estensione di layer-2 è il vero requisito

Alcuni progetti hanno davvero bisogno di un comportamento Ethernet tra siti: un’applicazione legacy che dipende dal rilevamento tramite broadcast, una migrazione che deve conservare un indirizzo mentre una macchina si sposta, o un protocollo che incorpora presupposti di layer-2. Quei casi richiedono un overlay o un servizio pontato che trasporti i frame, e allora l’appartenenza al VLAN, la prevenzione dei loop e la gestione dei guasti diventano questioni end-to-end.

È un dominio di guasto molto più grande, e dovrebbe essere una scelta deliberata invece del risultato accidentale di un tentativo di far funzionare una condivisione file. Un normale file server, database o applicazione web ha bisogno di un percorso IP autorizzato, e sarà più felice senza un dominio di broadcast esteso sotto di sé.

Scrivete il contratto VPN come prefissi raggiungibili più servizi consentiti, e registrate l’etichetta VLAN solo dove le operazioni locali ne hanno bisogno. Ogni ufficio può allora rinumerare la propria commutazione senza trasformare ogni cambiamento in una riprogettazione del tunnel.