OpenVPN TUN contro TAP: tre condizioni che decidono

Due tunnel possono trasportare lo stesso trasferimento di file e differire completamente in ciò che mettono sul filo. Uno sposta pacchetti IP tra due indirizzi; l'altro sposta frame Ethernet e può essere collegato in bridge in un segmento. Questa differenza decide quali applicazioni funzionano, quali client possono connettersi e quanto progetto di rete ti assumi.

Tre condizioni lo risolvono in pratica. Affrontale in ordine, perché la prima di solito chiude la discussione.

Che cosa trasporta davvero ogni interfaccia

Un dispositivo TUN è un'interfaccia punto a punto di livello 3: il kernel le consegna pacchetti IP e il tunnel li porta a un indirizzo peer. Un dispositivo TAP è un'interfaccia di livello 2 che trasporta frame Ethernet, ed è ciò che rende possibile il bridging, come descrive la documentazione del kernel. Nessuno dei due cambia il modo in cui il payload viene cifrato, e nessuno dei due è un'impostazione di forza. La scelta riguarda ciò che gli estremi devono scambiarsi, non quanto bene è protetto il traffico.

Una conseguenza segue subito: entrambe le estremità devono essere d'accordo. Un client configurato per un tipo di dispositivo non può unirsi a un server configurato per l'altro, qualunque altra cosa corrisponda.

Condizione uno: serve davvero il livello due?

Il bridging guadagna la sua complessità quando un protocollo ha davvero bisogno dello stesso dominio di broadcast: traffico non IP, discovery che non può attraversare un router o un'applicazione che pretende di stare su un solo segmento. Tutto il resto è un problema di routing, e il routing lo risolve con molta meno macchineria. Estendere un segmento su un'area vasta estende anche i suoi broadcast, quindi prevenzione dei loop, pianificazione degli indirizzi e domini di guasto diventano tutti parte del progetto. È molto da accettare per un requisito che una singola rotta avrebbe soddisfatto.

Il test è concreto: nomina l'applicazione che fallisce su un tunnel instradato e spiega perché. Se la risposta è che le serve il broadcast, il livello due è la risposta onesta. Se la risposta è che qualcuno non riusciva a raggiungere un server, il requisito è una rotta o una regola del firewall.

Condizione due: i client possono farlo?

Il supporto non è uniforme. I client desktop in genere espongono entrambi i tipi di dispositivo, mentre i client mobili ed embedded spesso implementano solo la modalità instradata, e un profilo che si importa senza lamentele può comunque fallire quando prova a creare l'interfaccia. Controlla il client e la versione specifici invece di dedurre le funzionalità dal nome della piattaforma.

Un errore di opzione non supportata non è un invito a cancellare righe sconosciute finché l'importazione non riesce. Significa che il profilo e il client non sono d'accordo su ciò che è possibile, e la riparazione spetta all'operatore che ha emesso il profilo. Rimuovere un'opzione per zittire un validatore può produrre una connessione che sembra funzionare mentre omette in silenzio la proprietà che doveva fornire.

Condizione tre: è davvero una questione di interfaccia?

Due scelte adiacenti vengono incolpate dei problemi di interfaccia. Il dispositivo virtuale decide cosa entra nel tunnel, mentre UDP o TCP decide come si comporta il trasporto esterno, e nessuno dei due cura i trasferimenti che si bloccano. Quando i trasferimenti grandi si impuntano e quelli piccoli riescono, meritano attenzione la dimensione dei pacchetti e l'MTU.

Un client che si connette e poi non riesce a raggiungere un host interno di solito sta guardando il routing, una regola del firewall o un percorso di ritorno mancante.

Per un servizio gestito, usa la disposizione delle interfacce specificata dal profilo dell'operatore, perché il lato server è già costruito intorno ad essa. Per un deployment privato, scegli in base al requisito reale dell'applicazione e scrivi il motivo accanto alla scelta.

La domanda non è quale opzione sia più forte. È quale serve davvero al traffico.