OpenVPN-komprimering: afvis, modtag kun eller fuld LZO?

Tre linjer i en profil ser ud til at slå komprimering fra, og kun én af dem gør det faktisk. Forskellen betyder noget, fordi den advarsel, du vil have til at forsvinde, er et symptom, mens politikken afgør, om modparten stadig kan komprimere. Sammenligner man mulighederne på én akse, nemlig hvad hver af dem tillader efter ændringen, forsvinder det meste af uklarheden. Hvilken du vil have, afhænger af, om du migrerer eller slår dig ned.

Tre politikker, der ser ens ud i en konfigurationsfil

Hver mulighed besvarer et forskelligt spørgsmål. allow-compression no afviser komprimerede nyttelaster helt, allow-compression asym dekomprimerer det, der ankommer, og komprimerer aldrig det, der sendes, og den gamle comp-lzo no efterlader plads til, at et push fra modparten aktiverer komprimering. Kun den første er en politik, som en server ikke kan tilsidesætte.

Skriv de tre ind i en tabel, før du vælger, fordi navnene er tæt nok på hinanden til at vildlede en anmelder. To af dem kører stadig dekomprimeringskode på modtagne pakker, og det er netop det, sikkerhedsargumentet handler om. Den tredje fjerner evnen i stedet for at begrænse dens retning. Hvis ændringsnotatet siger, at komprimering er slået fra, opfylder præcis én række den sætning.

Advarslen, der startede undersøgelsen, er ikke målet. At bringe den til tavshed, mens en eftergivende politik bliver stående, giver en ren log og en uændret eksponering.

Hvad no betyder på den gamle LZO-mulighed

På den forældede LZO-mulighed slår no komprimering fra for den lokale side, uden at forhindre modparten i at aktivere den, hvor politikken tillader det. Den asymmetri er grunden til, at flytningen af en profil til en streng afvisning ændrer adfærd på måder, som en laboratorietest med én server måske aldrig afslører.

Sikkerhedsbekymringen er betinget, ikke absolut. Når en angriber kan placere valgt klartekst ved siden af en hemmelighed og se, hvordan komprimering ændrer størrelsen på krypteret trafik, findes der en informationskanal. Skiftet fra LZO til LZ4 ændrer algoritmen og indramningen, ikke den mekanisme.

Den ærlige ramme handler altså om, hvad du er villig til at tillade, ikke om hvilken algoritme der anbefales i øjeblikket. Streng afvisning er den eneste mulighed, der ikke afhænger af modpartens samarbejde.

Kun modtagelse er en migreringstilstand, ikke en destination

Asymmetrisk accept findes, så den ene side kan holde op med at komprimere, mens den anden stadig forventer det. Det er en bro, og broer har brug for en slutdato og en ejer. Notér hvilke parter der stadig sender komprimeret trafik, fordi politikken tillader netop den trafik. Uden den liste bliver migreringstilstanden den permanente konfiguration af sig selv.

En klient kan ikke tvinge en inkompatibel server til at opgive den gamle indramning ved at redigere sin egen fil. Push-retningen besluttes på serveren, så serverkonfigurationen og dens filer per klient er der, hvor migreringen faktisk afsluttes.

Stub-tilstande bevarer indramningen, mens de springer selve komprimeringsarbejdet over, og de er ikke en direkte erstatning for den ældre mulighed. Test dem mod den ældste part, du stadig skal understøtte, før du vælger en.

Hvor offload af datakanalen ændrer svaret

Offload af datakanalen flytter pakkehåndtering ind i kernen, og en profil, der stadig afhænger af komprimeringsindramning, passer måske ikke på den offloadede vej. Fejlen er ikke altid højlydt: en klient opretter forbindelse og opfører sig derefter anderledes end den tunnel, du testede.

Kontroller, hvilken implementering der er aktiv før og efter ændringen, ikke kun om forbindelsen lykkes. Når den offloadede vej afviser komprimeringsindramning, passer en streng afvisningspolitik og en offloadet udrulning sammen, mens en eftergivende politik og en offloadet udrulning ikke gør.

Den kombination fortjener sin egen test, for det er netop der, en fil, der ser korrekt ud, i stilhed ikke er den, der bruges. Sammenlign den forhandlede tilstand med hensigten registreret i profilen, fordi kun én af dem er synlig i en log.

Vælg en politik, og verificér derefter det forhandlede resultat

Vælg streng afvisning, når du kan ændre begge ender, asymmetrisk accept, når du ikke kan endnu, og fuld komprimering kun, når du kan forklare, hvorfor eksponeringen er acceptabel. Verificér derefter, hvad der blev forhandlet, i stedet for hvad filen siger. En mere stille log er kun bevis, når den matcher den politik, du havde tænkt at udrulle.

Hold beslutningen ved siden af den profil, den gælder for, med datoen og de parter, der stadig er undtaget. Seks måneder senere er den note forskellen mellem en bevidst undtagelse og et uheld, som ingen kan datere. Skriv den i samme repository som profilen, så den næste redaktør ser årsagen før direktivet.