Un tunnel compra topologia, non cifratura o latenza

Il presupposto è che un tunnel sia un filo privato e veloce: lo si costruisce, il traffico all’interno è cifrato, il percorso è più breve e il collegamento si comporta come un cavo tra due sedi. Ogni parte di questo presupposto è una proprietà separata, e il tunnel fornisce solo la prima cosa che gli è stata chiesta, cioè un percorso logico. Tutto il resto deve essere scelto e configurato di proposito. Confondere le proprietà è il modo in cui un progetto finisce con un collegamento cifrato che nessuno riesce a diagnosticare e con una promessa di latenza che nessuno riesce a mantenere.

Il mito: un tunnel, tre garanzie

Un tunnel fa una cosa in modo affidabile. Fa sì che due estremità non collegate direttamente si comportino come se fossero adiacenti per uno scopo, mentre la rete intermedia trasporta i pacchetti esterni. È un cambiamento di topologia, ed è davvero utile di per sé.

Cifratura, trasporto di protocolli e isolamento dell’inoltro sono decisioni separate sovrapposte. Un tunnel GRE non ne ha nessuna delle tre in senso crittografico, e un tunnel IP-in-IP è un progetto valido senza alcuna riservatezza. Nessuno dei due è un errore; sono tunnel che fanno esattamente ciò che fanno i tunnel. L’etichetta sul diagramma non dice quali proprietà siano presenti.

Una volta separate le proprietà, le domande diventano rispondibili: questo tunnel trasporta un’adiacenza di routing, trasporta frame, nasconde gli indirizzi interni, promette qualcosa sul ritardo? Sono quattro risposte diverse con quattro diverse conseguenze di configurazione.

Che cosa aggiunge davvero il tunnel alla mappa

Le estremità ottengono un percorso che prima non avevano. Se quel percorso si comporti come un salto instradato o come un segmento Ethernet dipende interamente dall’incapsulamento, e la differenza cambia ciò che le due sedi possono farne. Un tunnel instradato vi dà un prossimo salto e un prefisso; un’estensione Ethernet vi dà comportamento di broadcast e un dominio di guasto molto più grande.

Un tunnel IP non rende automaticamente la sede remota parte della stessa sottorete, e non fa girare un protocollo di routing attraverso di esso a meno che l’implementazione supporti quell’adiacenza. Il multicast è un’altra domanda separata con la propria risposta.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Quei comandi rispondono a parti diverse della domanda. Il primo dice che tipo di interfaccia esiste, il secondo dice quale percorso sceglierebbe il kernel, e gli ultimi due mostrano il comportamento reale del sottostante invece della promessa dell’etichetta.

Il trasporto è una decisione separata dalla raggiungibilità

Un tunnel può trasportare un protocollo che il sottostante non inoltra. IPv6 su un percorso IPv4 è il caso classico, e funziona perché le estremità comprendono entrambe le famiglie mentre i router in mezzo devono solo consegnare i pacchetti esterni. Il sottostante ha bisogno di un percorso funzionante verso l’estremità del tunnel e nient’altro.

Le estremità, però, hanno bisogno di pieno supporto: inoltro, indirizzi e un’applicazione che usi davvero la famiglia interna. Assegnare un prefisso IPv6 a un tunnel non rende un servizio che funziona solo con IPv4 raggiungibile tramite IPv6, e non rende il sottostante a doppio stack.

Il trasporto di frame è un impegno maggiore del trasporto di protocolli. Estendere un dominio di broadcast su un tunnel sposta con sé il comportamento dello spanning tree, ARP e la propagazione dei guasti, che è una decisione di progetto e non un interruttore di funzionalità.

L’isolamento non è riservatezza

Le VPN dei provider tengono rotte e traffico dei clienti in contesti di inoltro separati, e quella separazione è reale e preziosa. Non è cifratura. La specifica BGP/MPLS VPN dice esplicitamente che la sua privatezza viene dal modello di inoltro e non dalla crittografia, ed è esattamente la distinzione che si perde in una diapositiva che dice solo VPN.

Se avete bisogno di riservatezza, avete bisogno di un meccanismo crittografico con autenticazione e gestione delle chiavi, e dovete sapere dove termina. Un tunnel che fornisce separazione e un tunnel che fornisce cifratura possono essere lo stesso tunnel, ma solo quando qualcuno ha configurato entrambi.

La conseguenza pratica è che «è dentro una VPN» risponde a una domanda sul contesto di routing e non vi dice nulla su chi può leggere i byte sul percorso. Due team possono avere entrambi ragione e comunque descrivere cose diverse. Quando sorge la domanda di sicurezza, chiedete dove termina la crittografia e che cosa autentica i peer, non se esiste un tunnel.

Latenza e QoS seguono il sottostante

Un bordo logico non è un percorso fisico più corto. I pacchetti esterni attraversano ancora gli stessi collegamenti, code e provider, e l’incapsulamento aggiunge overhead per pacchetto più elaborazione alle due estremità. Un tunnel può essere veloce perché il sottostante è buono, mai perché è un tunnel.

Il trattamento della qualità del servizio è peggiore, perché dipende da domini amministrativi che potreste non controllare. Le marcature interne devono essere mappate deliberatamente su quelle esterne, e ogni provider sul percorso deve offrire il trattamento che vi aspettate. La cifratura non crea priorità; nasconde il campo che un apparato intermedio avrebbe potuto usare per classificare il flusso.

Misurate il sottostante prima di promettere qualcosa. Un rapporto che mostra ritardo stabile e nessuna perdita sul percorso esterno è una prova; un diagramma con un tunnel sopra non lo è.

Scegliete il tunnel per la relazione di rete che vi serve, poi specificate separatamente cifratura, politica di accesso, dimensione dei pacchetti e prestazioni. Quattro decisioni, quattro prove e nessuna etichetta singola che ne sostituisca alcuna.