VPN L2 contro tunnel L3: cinque controlli prima di pontare un sito

Pontate un sito perché uno strumento insiste che deve stare sulla stessa rete, e tre settimane dopo state leggendo i log degli switch alle due di notte. Quel tipo di intuizione decide troppi collegamenti Ethernet su IP. Qui conta davvero una sola differenza: se viaggiano frame interi da un capo all'altro o solo pacchetti IP. Eseguite i cinque controlli qui sotto in ordine e fermatevi al primo che fallisce.

Controllate cosa mette davvero l'applicazione sul filo

Prima che un nome di prodotto entri nella discussione, catturate un minuto del traffico che deve attraversare il collegamento: tcpdump -i eth0 -nn -e 'not ip'. L'opzione -e stampa l'intestazione del livello di collegamento, ed è esattamente la parte che un tunnel instradato scarta. Se la cattura resta vuota, la vostra applicazione parla IP e un tunnel L3 la trasporta senza modifiche. Se compaiono dei frame, annotate l'EtherType, perché 0x0806 è ARP, 0x88cc è LLDP, e un valore del fornitore di solito significa un protocollo di discovery senza fallback IP. È il punto in cui una tun interfaccia normale non basta più.

Ripetete la cattura anche sul lato remoto. Un frame che esiste solo dentro lo switch virtuale di un singolo host non è un motivo per estendere un dominio di broadcast su una WAN.

Controllate se la discovery deve attraversare il collegamento

Un tunnel instradato non ha alcun segmento condiviso, quindi nulla indirizzato a un gruppo raggiunge l'altro capo. ARP, i broadcast DHCP, mDNS su 224.0.0.251, SSDP e le query di nome NetBIOS presuppongono tutti un collegamento che più host sentono contemporaneamente.

Chiedete da quali di essi dipende davvero l'applicazione e se esiste già un proxy per loro. Il relay DHCP, la riflessione mDNS e le voci ARP statiche rimuovono ciascuno una dipendenza, e ciascuno è un servizio in più da eseguire e monitorare. Quando ne restano due o tre, il ponte è la risposta onesta.

Controllate quanto vi costa l'intestazione in più

I frame devono pur vivere da qualche parte, quindi tutto ciò che inviate riceve una seconda pila di intestazioni attorno. In un overlay VXLAN questo significa un'intestazione IP esterna, un'intestazione UDP e un'intestazione VXLAN di 8 byte, che spinge un carico pieno di 1,500 byte oltre l'MTU di percorso di un normale collegamento internet da 1,500 byte. OpenVPN in modalità tap aggiunge il proprio sovraccarico nella stessa direzione. Senza un MTU più basso sul lato interno ottenete un collegamento che risponde ai ping e si blocca al primo trasferimento grande.

Il conto non si ferma ai byte di intestazione. Broadcast e multicast che uno switch gestisce in hardware ora viaggiano sulla WAN, e ogni sito pontato eredita lo stesso piano di indirizzi, lo stesso ambito DHCP e lo stesso comportamento con indirizzi duplicati. Questo rende il collegamento molto più difficile da verificare di un pool instradato con un prefisso per sito.

Fate i conti prima di scegliere. Un segmento trafficato replicato su tre siti può spostare più traffico broadcast dei trasferimenti di file per cui è stato costruito.

Controllate che tipo di VPN L2 vi stanno offrendo

Il termine stesso è ambiguo, e l'ambiguità decide chi trasporta il vostro traffico. A volte descrive il carico: frame Ethernet dentro IP, inviati su internet come qualsiasi altro tunnel, come fanno VXLAN, ZeroTier e la modalità tap di OpenVPN. A volte descrive un servizio acquistato: un circuito Ethernet di operatore o uno pseudocavo MPLS che unisce due siti dentro un'unica rete di fornitore.

Entrambi vi danno un segmento, quindi l'applicazione non può distinguerli, ma la differenza operativa è grande. Un overlay vi lascia la responsabilità di MTU, cifratura e percorso sottostante. Un servizio di operatore se ne fa carico e lo fattura, e non instraderà affatto i vostri frame sulla rete internet pubblica. Quale vogliate dipende dal fatto che i due siti condividano un operatore o solo un'azienda.

Controllate la soluzione più economica prima di pontare

La maggior parte delle richieste di un collegamento pontato viene da un'unica risoluzione rotta, non da un protocollo che ha davvero bisogno di frame. Fate passare prima il resolver e il dominio di ricerca dal tunnel instradato: dhcp-option DNS 10.8.0.1 insieme a dhcp-option DOMAIN internal.example in una configurazione di server OpenVPN ne risolve un numero sorprendente. Un forwarder locale sul lato remoto fa lo stesso lavoro senza spostare alcun traffico broadcast.

Se uno strumento legacy continua a fallire, mettete quello strumento dietro un proxy o un jump host sul segmento di destinazione. Un singolo forwarder TCP costa meno da gestire di una WAN pontata.

Chiudete la decisione in ordine: il traffico porta un EtherType non IP, la discovery deve attraversare, l'MTU può assorbire le intestazioni extra, un circuito di fornitore è realmente disponibile, e la soluzione instradata è fallita per un motivo che sapete nominare? Un no a qualsiasi passo chiude la discussione a favore del tunnel che avete già. Archiviate la cattura e l'elenco degli EtherType con il registro delle modifiche, perché la persona successiva farà la stessa domanda e non vorrà ripetere la misura.