Perché il tuo sensore VPN non vede mai il tag VLAN della filiale

Un sensore dal lato VPN vede due VLAN di filiale come traffico IP semplice, e il tag che identificava ogni filiale sul proprio cavo è sparito. È ciò che fa un tunnel instradato: recupera pacchetti, non le cornici Ethernet che li hanno consegnati. Se il tag mancante abbia importanza dipende interamente dalla domanda che poni al sensore. Esegui i quattro controlli qui sotto in ordine e saprai quale punto di osservazione può rispondervi.

Primo: stabilisci che cosa recupera il tuo tunnel

Un’interfaccia TUN trasporta pacchetti IP, quindi l’intestazione VLAN della cornice di filiale si ferma al router che ha spinto il traffico nel tunnel. Un’interfaccia TAP trasporta cornici Ethernet, il che significa che i tag possono sopravvivere quando il bridge e le regole di ammissione VLAN li lasciano passare. Leggi il tipo di interfaccia prima di ragionare su che cosa dovrebbe contenere una cattura.

Nessuna delle due scelte è un difetto. I due progetti rispondono a domande diverse e lasciano il tag in punti diversi.

Verifica l’interfaccia tu stesso invece di dedurla dal nome del prodotto. I dettagli del collegamento indicano il tipo di dispositivo e mostrano i flag in vigore, e una cattura presa su un dispositivo TUN non guadagnerà un’intestazione Ethernet solo perché l’hai chiesta. Se i tag compaiono comunque in una cattura TUN, quasi certamente stai leggendo un’altra interfaccia o un tunnel che trasporta cornici dentro il proprio carico utile. Annota in quale caso ti trovi prima di continuare.

Secondo: colloca il sensore dove l’oggetto esiste ancora

Tre posizioni coprono la maggior parte dei progetti instradati: il segmento Ethernet della filiale, la rete esterna tra gli estremi del tunnel e il percorso dopo l’elaborazione del tunnel. Ognuna vede un oggetto diverso, e il tag esiste solo nella prima. Scegliere una posizione del sensore è una decisione su quale oggetto serva alla politica, non una questione di comodità.

Poni la domanda di politica in termini a cui la tabella può rispondere, e di solito si risolve da sola. Se la regola deve sapere da quale filiale è venuto un pacchetto, la mappatura dei prefissi a valle può bastare, ma solo finché quella mappatura resta esatta e non ambigua. Se la regola deve sapere su quale porta è arrivata la cornice, ti serve la prima posizione, perché nulla a valle può ricostruirla. I sensori collocati per abitudine invece che per domanda sono il modo in cui i team finiscono per pretendere un campo che il progetto non ha mai portato.

Un tunnel che trasporta Ethernet è un progetto diverso e richiede un proprio controllo di ciò che gli estremi conservano o riscrivono. Scegliere TAP da solo non definisce ancora il bridge, le regole di ammissione VLAN o la politica di ispezione.

Terzo: guadagnati il contesto di origine invece di fidarti

Un intervallo di indirizzi per filiale è il sostituto abituale dell’identità VLAN, e regge solo finché la mappatura resta uno a uno. Prefissi sovrapposti, traduzione e un gateway condiviso spezzano ciascuno quell’ipotesi in un modo che sembra un problema di qualità dei dati e non di progetto. Scrivi la mappatura con i suoi confini e di’ che cosa succede a un pacchetto che corrisponde a due righe. Un prefisso che compare in due filiali dovrebbe essere un errore che rilevi, non un lancio di moneta che accetti.

Il contesto fornito dal client non è prova di appartenenza. È un’affermazione, e appartiene a un’altra colonna.

Dove la distinzione conta, usa dati di associazione che controlli: quale istanza di tunnel ha accettato la connessione, su quale interfaccia sono arrivati i pacchetti, che cosa dice la tabella di routing locale di quel peer. Un’etichetta fornita dal client è un indizio utile e un input di autorizzazione inutile. Se il sensore non riesce a stabilire l’associazione dal proprio lato, la politica ha bisogno di una regola più ampia e non di una supposizione sicura.

Quarto: conferma il percorso di risposta e ciò che la decifratura manca

Un sensore che vede una sola direzione può ancora sembrare sano, perché le richieste continuano ad arrivare puntuali. Controlla il percorso di risposta in modo esplicito, e controllalo per lo stesso flusso e non per la raggiungibilità generale. La visibilità half-duplex diventa un vuoto silenzioso in ogni conclusione con stato che ne trai.

Recuperare il traffico IP interno non è nemmeno lo stesso che vedere l’applicazione al suo interno, perché il TLS trasportato sul tunnel resta TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

Quei due comandi rispondono alla domanda sull’interfaccia e mostrano che cosa contiene davvero la cattura, il che è più rapido che discutere dell’architettura. Sostituisci il nome di interfaccia che usa il tuo progetto ed esegui la cattura mentre il flusso che ti interessa è attivo. Quando su un dispositivo TUN non compare alcun tag, il risultato è che il progetto ha instradato invece di fare bridging, non che il sensore abbia perso dati. Poi sposta il sensore in una posizione che possa vedere il tag, oppure riscrivi la regola in termini che la posizione attuale possa sostenere.