OpenVPN-komprimering: neka, bara ta emot eller full LZO?
comp-lzo no är inte ett strikt neka. Jämför att neka komprimering, att acceptera den åt ett håll under en migrering och att behålla den, och kontrollera sedan vad offload gör.
Tre rader i en profil ser ut att stänga av komprimering allihop, och bara en av dem gör det faktiskt. Skillnaden spelar roll eftersom varningen du vill tysta är ett symptom, medan policyn avgör om motparten fortfarande kan komprimera. Att jämföra alternativen på en axel, nämligen vad vart och ett tillåter efter ändringen, tar bort det mesta av oklarheten. Vilket du vill ha beror på om du migrerar eller sätter dig till rätta.
Tre policyer som ser likadana ut i en konfigurationsfil
Varje alternativ svarar på en annan fråga. allow-compression no nekar komprimerade nyttolaster direkt, allow-compression asym dekomprimerar det som kommer in och komprimerar aldrig det som går ut, och den gamla comp-lzo no lämnar utrymme för en push från motparten som slår på komprimering. Bara den första är en policy som en server inte kan åsidosätta.
Skriv de tre i en tabell innan du väljer, eftersom namnen ligger nära nog att vilseleda en granskare. Två av dem kör fortfarande dekomprimeringskod på mottagna paket, och det är precis vad säkerhetsargumentet handlar om. Det tredje tar bort förmågan i stället för att begränsa dess riktning. Om ändringsprotokollet säger att komprimering är avstängd, uppfyller exakt en rad den meningen.
Varningen som startade undersökningen är inte målet. Att tysta den medan en tillåtande policy står kvar ger en ren logg och en oförändrad exponering.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
Vad no betyder på det gamla LZO-alternativet
På det utfassade LZO-alternativet stänger no av komprimering för den lokala sidan utan att förbjuda motparten att slå på den där policyn tillåter det. Den asymmetrin är anledningen till att flytten av en profil till ett strikt neka ändrar beteendet på sätt som ett labbtest med en enda server kanske aldrig avslöjar.
Säkerhetsbekymret är villkorat, inte absolut. När en angripare kan placera vald klartext intill en hemlighet och se hur komprimering ändrar storleken på krypterad trafik, finns en informationskanal. Att byta från LZO till LZ4 ändrar algoritmen och inramningen, inte den mekanismen.
Det ärliga ramverket handlar alltså om vad du är beredd att tillåta, inte om vilken algoritm som rekommenderas nu. Strikt neka är det enda alternativet som inte beror på motpartens samarbete.
Bara mottagning är ett migreringstillstånd, inte en destination
Asymmetrisk acceptans finns så att ena sidan kan sluta komprimera medan den andra fortfarande förväntar sig det. Det är en bro, och broar behöver ett slutdatum och en ägare. Notera vilka parter som fortfarande skickar komprimerad trafik, eftersom policyn tillåter just den trafiken. Utan den listan blir migreringstillståndet den permanenta konfigurationen av sig själv.
En klient kan inte tvinga en inkompatibel server att överge den gamla inramningen genom att redigera sin egen fil. Push-riktningen avgörs på servern, så migreringen fullbordas faktiskt i serverkonfigurationen och dess filer per klient.
Stub-lägen bevarar inramningen men hoppar över själva komprimeringsarbetet, och de är inte en direkt motsvarighet till det äldre alternativet. Testa dem mot den äldsta parten du fortfarande måste stödja innan du väljer en.
Där offload av datakanalen ändrar svaret
Offload av datakanalen flyttar pakethanteringen in i kärnan, och en profil som fortfarande beror på komprimeringsinramning passar kanske inte på den utlokaliserade vägen. Felet är inte alltid högljutt: en klient ansluter och beter sig sedan annorlunda än tunneln du testade.
Kontrollera vilken implementering som är aktiv före och efter ändringen, inte bara om anslutningen lyckas. När den utlokaliserade vägen nekar komprimeringsinramning stämmer en strikt nekande policy och en utlokaliserad driftsättning överens, medan en tillåtande policy och en utlokaliserad driftsättning inte gör det.
Den kombinationen förtjänar sitt eget test, för det är just där en fil som ser korrekt ut i tysthet inte är den som används. Jämför det förhandlade tillståndet med avsikten som registrerats i profilen, eftersom bara en av dem syns i en logg.
Välj en policy och verifiera sedan det förhandlade resultatet
Välj strikt neka när du kan ändra båda ändarna, asymmetrisk acceptans när du inte kan än, och full komprimering bara när du kan motivera varför exponeringen är acceptabel. Verifiera sedan vad som förhandlades i stället för vad filen säger. En tystare logg är bara bevis när den stämmer med policyn du avsåg att driftsätta.
Håll beslutet bredvid profilen det gäller, med datumet och parterna som fortfarande är undantagna. Ett halvår senare är den anteckningen skillnaden mellan ett medvetet undantag och en olycka som ingen kan datera. Skriv den i samma repositorium som profilen, så att nästa redaktör ser skälet före direktivet.