TUN/TAP: argomento non valido — disallineamento del framing OpenVPN

Il client si autentica, il log dice connesso, e nessun pacchetto attraversa il tunnel. Il server termina il tentativo con write to TUN/TAP: Invalid argument (code=22), che sembra un guasto del driver e di solito non lo è. Su router e piccoli server Linux, quella riga spesso significa che i due peer non concordano su come vengono incorniciati i pacchetti dati, quindi il kernel rifiuta il buffer decifrato che gli è stato consegnato. L’instradamento non è ancora stato testato in quel punto.

Una tabella di instradamento corretta e un accordo di framing rotto appaiono uguali dal client: connesso, e nulla funziona.

Il tunnel sale e nulla lo attraversa

Gli errori di scrittura sul dispositivo del tunnel avvengono dopo la decifratura e prima dell’instradamento. Il demone decifra un pacchetto, lo consegna all’interfaccia, e l’interfaccia lo rifiuta perché il buffer non corrisponde a ciò che quel dispositivo si aspetta. Il codice 22 è la risposta generica di argomento non valido, quindi l’informazione utile è lo strato: questo è il percorso dati e non l’handshake. Se il traffico funzionava ieri e si è fermato oggi senza alcuna modifica di configurazione, sospettate un aggiornamento di pacchetto o firmware che ha spostato un valore predefinito prima di sospettare la rete.

Leggete il log attorno alla configurazione del canale dati invece del primo errore. La modalità di compressione negoziata, il tipo dev e le opzioni inviate compaiono tutti a verbosità più alta, e vi dicono quale dei tre disallineamenti avete.

La compressione è framing, non larghezza di banda

Con la compressione attiva, ogni pacchetto dati porta un’intestazione che descrive come è stato codificato, ed entrambe le estremità devono concordare su quell’intestazione. Un server che porta ancora comp-lzo da una vecchia configurazione di esempio, abbinato a un client senza riga di compressione, produce esattamente questo errore: il server si aspetta un’intestazione che il client non ha mai scritto. Mescolare comp-lzo con compress lz4-v2 fallisce allo stesso modo, poiché gli algoritmi differiscono anche se entrambi si chiamano compressione. L’opzione è un contratto di framing e non una funzione di larghezza di banda sui collegamenti moderni.

Il comportamento delle versioni aggiunge una trappola. La serie 2.5 ha iniziato a emettere avvisi di obsolescenza per le opzioni di compressione, e 2.6 traccia una linea tra rifiutare i pacchetti compressi e lasciare semplicemente i dati non compressi. Un aggiornamento del firmware del router può quindi cambiare l’accordo effettivo senza che nessuno modifichi il tunnel.

Allineate entrambe le estremità o rimuovetelo da entrambe

Elencate ogni direttiva di compressione: il file del server, eventuali opzioni inviate, i file specifici del client e il profilo del client. comp-lzo sul server richiede la stessa parola sul client, e adaptive è il valore predefinito legacy che l’opzione nuda di solito significa nelle build più vecchie. L’interruttore della GUI del router etichettato LZO o compressione scrive quella stessa opzione, quindi impostalo per corrispondere invece di mescolare algoritmi. Non date per scontato che un nome dall’aspetto simile sia compatibile.

Se la compressione non è desiderata, rimuovetela deliberatamente da entrambe le estremità. allow-compression no sul server rifiuta i pacchetti compressi, ma solo dopo che i client hanno smesso di offrirli; applicarlo mentre un client invia ancora compressione ricrea il disallineamento nella direzione opposta.

Controllate l’invio e il tipo di dispositivo

Un server può inviare una direttiva di compressione dal suo file principale o da un file specifico del client, e un client può scartare le opzioni inviate con pull-filter. Collegate un client a verbosità 4, leggete ciò che il server ha annunciato rispetto a ciò che il client ha accettato, poi confermate che nessun filtro lo abbia rimosso. Se entrambi i lati ora concordano e l’errore persiste, guardate il tipo di dispositivo: dev tap a un’estremità e dev tun all’altra non possono scambiarsi frame, e il kernel rifiuta la scrittura allo stesso modo.

Un deployment TAP con bridge richiede un bridge reale sul server, non solo un nome di dispositivo diverso. Rinominare un’interfaccia in tap0 senza aggiungerla a un bridge produce un dispositivo che accetta la scrittura e non va da nessuna parte.

Poi verificate con un client e una destinazione: fate ping all’indirizzo del tunnel del server, poi a un host sulla sua LAN. Il primo prova il canale dati e il secondo l’inoltro.