Compressione OpenVPN: rifiutare, ricevere soltanto o LZO completo?

Tre righe di un profilo sembrano tutte disattivare la compressione, e solo una lo fa davvero. La differenza conta perché l'avviso che volete silenziare è un sintomo, mentre la politica è ciò che decide se l'altra estremità può ancora comprimere. Confrontare le opzioni su un solo asse, cioè ciò che ciascuna permette dopo la modifica, elimina gran parte dell'ambiguità. Quale volete dipende dal fatto che stiate migrando o assestandovi.

Tre politiche che in un file di configurazione sembrano identiche

Ogni opzione risponde a una domanda diversa. allow-compression no rifiuta del tutto i payload compressi, allow-compression asym decomprime ciò che arriva e non comprime mai ciò che parte, e la vecchia comp-lzo no lascia spazio a un push dell'altra estremità per attivare la compressione. Solo la prima è una politica che un server non può scavalcare.

Scrivete le tre in una tabella prima di scegliere, perché i nomi sono abbastanza simili da trarre in inganno un revisore. Due di esse eseguono ancora codice di decompressione sui pacchetti ricevuti, ed è esattamente di questo che parla l'argomento di sicurezza. La terza rimuove la capacità invece di limitarne la direzione. Se il verbale della modifica dice che la compressione è disattivata, esattamente una riga soddisfa quella frase.

L'avviso che ha avviato l'indagine non è l'obiettivo. Silenziarlo lasciando in piedi una politica permissiva produce un registro pulito e un'esposizione invariata.

Che cosa significa no nella vecchia opzione LZO

Nell'opzione LZO obsoleta, no disattiva la compressione per il lato locale senza vietare all'altra estremità di attivarla dove la politica lo consente. È questa asimmetria che fa sì che passare un profilo a un rifiuto rigoroso cambi il comportamento in modi che un test di laboratorio con un solo server potrebbe non rivelare mai.

La preoccupazione di sicurezza è condizionale, non assoluta. Quando un attaccante può collocare testo in chiaro scelto accanto a un segreto e osservare come la compressione cambia la dimensione del traffico cifrato, esiste un canale informativo. Passare da LZO a LZ4 cambia l'algoritmo e l'incapsulamento, non quel meccanismo.

Quindi l'inquadramento onesto riguarda ciò che siete disposti a permettere, non quale algoritmo sia raccomandato ora. Il rifiuto rigoroso è l'unica opzione che non dipende dalla collaborazione dell'altra estremità.

Ricevere soltanto è uno stato di migrazione, non una destinazione

L'accettazione asimmetrica esiste perché un'estremità possa smettere di comprimere mentre l'altra se lo aspetta ancora. È un ponte, e i ponti hanno bisogno di una data di fine e di un responsabile. Annotate quali peer inviano ancora traffico compresso, perché la politica permette esattamente quel traffico. Senza quell'elenco, lo stato di migrazione diventa la configurazione permanente per inerzia.

Un client non può costringere un server incompatibile ad abbandonare il vecchio incapsulamento modificando il proprio file. La direzione del push si decide sul server, quindi la migrazione si conclude davvero nella configurazione del server e nei suoi file per client.

Le modalità stub conservano l'incapsulamento ma saltano il lavoro di compressione vero e proprio, e non sono un equivalente diretto della vecchia opzione. Provatele contro il peer più vecchio che dovete ancora supportare prima di impegnarvi su una.

Dove l'offload del canale dati cambia la risposta

L'offload del canale dati sposta la gestione dei pacchetti nel kernel, e un profilo che dipende ancora dall'incapsulamento di compressione potrebbe non adattarsi a quel percorso. Il guasto non è sempre rumoroso: un client si connette e poi si comporta diversamente dal tunnel che avete provato.

Verificate quale implementazione è attiva prima e dopo la modifica, non solo se la connessione riesce. Quando il percorso con offload rifiuta l'incapsulamento di compressione, una politica di rifiuto rigoroso e un deployment con offload concordano, mentre una politica permissiva e un deployment con offload no.

Quella combinazione merita un test a sé, perché è esattamente lì che un file che sembra corretto non è silenziosamente quello in uso. Confrontate lo stato negoziato con l'intento registrato nel profilo, perché solo uno dei due è visibile in un registro.

Scegliete una politica, poi verificate il risultato negoziato

Scegliete il rifiuto rigoroso quando potete cambiare entrambe le estremità, l'accettazione asimmetrica quando non potete ancora, e la compressione completa solo quando sapete spiegare perché l'esposizione è accettabile. Poi verificate ciò che è stato negoziato invece di ciò che dice il file. Un registro più silenzioso è una prova solo quando corrisponde alla politica che intendevate distribuire.

Tenete la decisione accanto al profilo a cui si applica, con la data e i peer ancora esentati. Sei mesi dopo, quella nota è la differenza tra un'eccezione deliberata e un incidente che nessuno sa datare. Scrivetela nello stesso repository del profilo, così il prossimo editor vede il motivo prima della direttiva.