OpenVPN-komprimering: avvise, bare motta eller full LZO?

Tre linjer i en profil ser ut til å slå av komprimering alle sammen, og bare én av dem gjør det faktisk. Forskjellen betyr noe fordi advarselen du vil stilne er et symptom, mens policyen avgjør om motparten fortsatt kan komprimere. Å sammenligne alternativene på én akse, nemlig hva hvert av dem tillater etter endringen, fjerner det meste av uklarheten. Hvilket du vil ha avhenger av om du migrerer eller fester deg.

Tre policyer som ser like ut i en konfigurasjonsfil

Hvert alternativ svarer på et ulikt spørsmål. allow-compression no avviser komprimerte nyttelaster helt, allow-compression asym dekomprimerer det som kommer inn og komprimerer aldri det som går ut, og den gamle comp-lzo no gir rom for en push fra motparten som slår på komprimering. Bare det første er en policy en server ikke kan overstyre.

Skriv de tre i en tabell før du velger, fordi navnene er nære nok til å villede en gjennomleser. To av dem kjører fortsatt dekomprimeringskode på mottatte pakker, og det er nettopp det sikkerhetsargumentet handler om. Det tredje fjerner evnen i stedet for å begrense retningen. Hvis endringsnotatet sier at komprimering er slått av, oppfyller nøyaktig én rad den setningen.

Advarselen som startet undersøkelsen er ikke målet. Å stilne den mens en ettergivende policy blir stående gir en ren logg og en uendret eksponering.

Hva no betyr på det gamle LZO-alternativet

På det utdaterte LZO-alternativet slår no av komprimering for den lokale siden uten å forby motparten å slå den på der policyen tillater det. Denne asymmetrien er grunnen til at flytting av en profil til en streng avvisning endrer atferd på måter en laboratorietest med én server kanskje aldri avdekker.

Sikkerhetsbekymringen er betinget, ikke absolutt. Når en angriper kan plassere valgt klartekst ved siden av en hemmelighet og se hvordan komprimering endrer størrelsen på kryptert trafikk, finnes det en informasjonskanal. Å bytte fra LZO til LZ4 endrer algoritmen og innrammingen, ikke den mekanismen.

Den ærlige innrammingen handler altså om hva du er villig til å tillate, ikke om hvilken algoritme som anbefales nå. Streng avvisning er det eneste alternativet som ikke avhenger av samarbeid fra den andre enden.

Bare mottak er en migreringstilstand, ikke en destinasjon

Asymmetrisk aksept finnes for at den ene siden kan slutte å komprimere mens den andre fortsatt forventer det. Det er en bro, og broer trenger en sluttdato og en eier. Noter hvilke parter som fortsatt sender komprimert trafikk, fordi policyen tillater nettopp den trafikken. Uten den listen blir migreringstilstanden den permanente konfigurasjonen av seg selv.

En klient kan ikke tvinge en inkompatibel server til å forlate den gamle innrammingen ved å redigere sin egen fil. Push-retningen avgjøres på serveren, så migreringen fullføres faktisk i serverkonfigurasjonen og dens filer per klient.

Stub-moduser bevarer innrammingen mens de hopper over selve komprimeringsarbeidet, og de er ikke en direkte erstatning for det eldre alternativet. Test dem mot den eldste parten du fortsatt må støtte før du velger en.

Hvor offload av datakanalen endrer svaret

Offload av datakanalen flytter pakkehåndtering inn i kjernen, og en profil som fortsatt avhenger av komprimeringsinnramming passer kanskje ikke på den utlastede veien. Feilen er ikke alltid høylytt: en klient kobler til og oppfører seg deretter annerledes enn tunnelen du testet.

Sjekk hvilken implementasjon som er aktiv før og etter endringen, ikke bare om tilkoblingen lykkes. Når den utlastede veien avviser komprimeringsinnramming, passer en streng avvisningspolicy og en utlastet utrulling sammen, mens en ettergivende policy og en utlastet utrulling ikke gjør det.

Den kombinasjonen fortjener sin egen test, for det er nettopp der en fil som ser riktig ut i stillhet ikke er den som brukes. Sammenlign den forhandlede tilstanden med intensjonen som er registrert i profilen, fordi bare én av dem er synlig i en logg.

Velg en policy, og verifiser deretter det forhandlede resultatet

Velg streng avvisning når du kan endre begge ender, asymmetrisk aksept når du ikke kan ennå, og full komprimering bare når du kan begrunne hvorfor eksponeringen er akseptabel. Verifiser deretter hva som ble forhandlet i stedet for hva filen sier. En stillere logg er bare bevis når den samsvarer med policyen du mente å rulle ut.

Hold beslutningen ved siden av profilen den gjelder for, med datoen og partene som fortsatt er unntatt. Et halvt år senere er den noten forskjellen mellom et bevisst unntak og en ulykke ingen kan datere. Skriv den i samme repositorium som profilen, slik at neste redaktør ser grunnen før direktivet.