Compresie în OpenVPN: refuz, doar recepție sau LZO complet?

Trei linii dintr-un profil par să dezactiveze toate compresia, și doar una o face cu adevărat. Diferența contează pentru că avertismentul pe care vreți să îl reduceți la tăcere este un simptom, în timp ce politica este cea care decide dacă cealaltă parte mai poate comprima. Compararea opțiunilor pe o singură axă, adică ce permite fiecare după schimbare, înlătură cea mai mare parte a ambiguității. Pe care o vreți depinde de faptul dacă migrați sau vă stabiliți.

Trei politici care arată la fel într-un fișier de configurare

Fiecare opțiune răspunde la o altă întrebare. allow-compression no refuză direct sarcinile comprimate, allow-compression asym decomprimă ce sosește și nu comprimă niciodată ce pleacă, iar vechea comp-lzo no lasă loc pentru un push al celeilalte părți care activează compresia. Doar prima este o politică pe care un server nu o poate anula.

Scrieți cele trei într-un tabel înainte de a alege, pentru că numele sunt suficient de apropiate ca să inducă în eroare un recenzent. Două dintre ele rulează încă cod de decomprimare pe pachetele primite, și exact despre asta este argumentul de securitate. A treia elimină capacitatea în loc să îi restrângă direcția. Dacă înregistrarea schimbării spune că compresia este dezactivată, exact un rând satisface acea propoziție.

Avertismentul care a declanșat investigația nu este obiectivul. Reducerea lui la tăcere lăsând o politică permisivă produce un jurnal curat și o expunere neschimbată.

Ce înseamnă no la vechea opțiune LZO

La opțiunea LZO învechită, no dezactivează compresia pentru partea locală fără a interzice celeilalte părți să o activeze acolo unde politica permite. Această asimetrie este motivul pentru care mutarea unui profil la un refuz strict schimbă comportamentul în moduri pe care un test de laborator cu un singur server poate să nu le descopere niciodată.

Îngrijorarea de securitate este condiționată, nu absolută. Când un atacator poate plasa text clar ales lângă un secret și poate observa cum compresia schimbă dimensiunea traficului criptat, există un canal de informație. Trecerea de la LZO la LZ4 schimbă algoritmul și încadrarea, nu acel mecanism.

Prin urmare, cadrul onest privește ce sunteți dispus să permiteți, nu care algoritm este recomandat acum. Refuzul strict este singura opțiune care nu depinde de cooperarea celeilalte părți.

Doar recepția este o stare de migrare, nu o destinație

Acceptarea asimetrică există pentru ca o parte să poată opri comprimarea în timp ce cealaltă încă o așteaptă. Este un pod, iar podurile au nevoie de o dată de încheiere și de un responsabil. Notați care parteneri mai trimit trafic comprimat, pentru că politica permite exact acel trafic. Fără acea listă, starea de migrare devine configurația permanentă prin inerție.

Un client nu poate obliga un server incompatibil să renunțe la încadrarea veche editându-și propriul fișier. Direcția push-ului se decide pe server, așa că migrarea se încheie de fapt în configurația serverului și în fișierele sale pentru fiecare client.

Modurile stub păstrează încadrarea dar sar peste munca de compresie propriu-zisă, și nu sunt un echivalent direct al opțiunii mai vechi. Testați-le pe cel mai vechi partener pe care încă trebuie să îl susțineți înainte de a alege unul.

Unde offload-ul canalului de date schimbă răspunsul

Offload-ul canalului de date mută procesarea pachetelor în kernel, iar un profil care încă depinde de încadrarea compresiei poate să nu se potrivească pe acea cale. Defecțiunea nu este întotdeauna zgomotoasă: un client se conectează și apoi se comportă diferit de tunelul pe care l-ați testat.

Verificați ce implementare este activă înainte și după schimbare, nu doar dacă conexiunea reușește. Când calea cu offload refuză încadrarea compresiei, o politică de refuz strict și un deployment cu offload sunt de acord, în timp ce o politică permisivă și un deployment cu offload nu sunt.

Această combinație merită un test propriu, pentru că exact acolo un fișier care pare corect nu este, în tăcere, cel folosit. Comparați starea negociată cu intenția înregistrată în profil, pentru că doar una dintre ele este vizibilă într-un jurnal.

Alegeți o politică, apoi verificați rezultatul negociat

Alegeți refuzul strict când puteți schimba ambele capete, acceptarea asimetrică când încă nu puteți, și compresia completă doar când puteți explica de ce expunerea este acceptabilă. Apoi verificați ce s-a negociat, nu ce spune fișierul. Un jurnal mai silențios este dovadă doar când corespunde politicii pe care intenționați să o implementați.

Țineți decizia lângă profilul căruia i se aplică, cu data și partenerii încă exceptați. După șase luni, acea notă este diferența dintre o excepție deliberată și un accident pe care nimeni nu îl poate data. Scrieți-o în același depozit ca profilul, ca următorul editor să vadă motivul înainte de directivă.