OpenVPN-compressie: weigeren, alleen ontvangen of volledige LZO?

Drie regels in een profiel lijken allemaal compressie uit te schakelen, en slechts één ervan doet dat echt. Het verschil is belangrijk omdat de waarschuwing die u wilt dempen een symptoom is, terwijl het beleid bepaalt of de andere kant nog kan comprimeren. De opties op één as vergelijken, namelijk wat elk ervan na de wijziging toestaat, neemt het grootste deel van de onduidelijkheid weg. Welke u wilt hangt ervan af of u migreert of zich vestigt.

Drie beleidsregels die er in een configuratiebestand hetzelfde uitzien

Elke optie beantwoordt een andere vraag. allow-compression no weigert gecomprimeerde payloads botweg, allow-compression asym decomprimeert wat binnenkomt en comprimeert nooit wat weggaat, en de oude comp-lzo no laat ruimte voor een push van de andere kant om compressie aan te zetten. Alleen de eerste is een beleid dat een server niet kan overrulen.

Schrijf de drie in een tabel voordat u kiest, want de namen lijken genoeg op elkaar om een beoordelaar te misleiden. Twee ervan voeren nog steeds decompressiecode uit op ontvangen pakketten, en daar gaat het beveiligingsargument precies over. De derde verwijdert de mogelijkheid in plaats van de richting ervan te beperken. Als het wijzigingsrecord zegt dat compressie is uitgeschakeld, voldoet precies één rij aan die zin.

De waarschuwing die het onderzoek startte is niet het doel. Die dempen terwijl een toegeeflijk beleid blijft staan, levert een schoon log en een onveranderde blootstelling op.

Wat no bij de oude LZO-optie betekent

Bij de verouderde LZO-optie schakelt no compressie uit voor de lokale kant zonder de andere kant te verbieden die aan te zetten waar het beleid dat toestaat. Door die asymmetrie verandert het verplaatsen van een profiel naar een strikte weigering gedrag op manieren die een labtest met één server misschien nooit onthult.

De beveiligingszorg is voorwaardelijk, niet absoluut. Wanneer een aanvaller gekozen leesbare tekst naast een geheim kan plaatsen en kan zien hoe compressie de omvang van versleuteld verkeer verandert, bestaat er een informatiekanaal. Van LZO naar LZ4 overstappen verandert het algoritme en de inkadering, niet dat mechanisme.

De eerlijke inkadering gaat dus over wat u bereid bent toe te staan, niet over welk algoritme nu wordt aanbevolen. Strikte weigering is de enige optie die niet afhangt van de medewerking van de andere kant.

Alleen ontvangen is een migratietoestand, geen bestemming

Asymmetrische acceptatie bestaat zodat de ene kant kan stoppen met comprimeren terwijl de andere het nog verwacht. Het is een brug, en bruggen hebben een einddatum en een eigenaar nodig. Noteer welke peers nog gecomprimeerd verkeer sturen, want het beleid staat precies dat verkeer toe. Zonder die lijst wordt de migratietoestand door traagheid de permanente configuratie.

Een client kan een incompatibele server niet dwingen de oude inkadering te verlaten door zijn eigen bestand te bewerken. De push-richting wordt op de server bepaald, dus de migratie eindigt feitelijk in de serverconfiguratie en de bestanden per client.

Stub-modi behouden de inkadering maar slaan het compressiewerk zelf over, en ze zijn geen direct equivalent van de oudere optie. Test ze tegen de oudste peer die u nog moet ondersteunen voordat u er een kiest.

Waar offload van het datakanaal het antwoord verandert

Offload van het datakanaal verplaatst pakketafhandeling naar de kernel, en een profiel dat nog van compressie-inkadering afhangt past mogelijk niet op dat pad. De fout is niet altijd luid: een client verbindt en gedraagt zich daarna anders dan de tunnel die u testte.

Controleer welke implementatie actief is voor en na de wijziging, niet alleen of de verbinding lukt. Wanneer het offload-pad compressie-inkadering weigert, komen een strikt weigerbeleid en een offload-implementatie overeen, terwijl een toegeeflijk beleid en een offload-implementatie dat niet doen.

Die combinatie verdient een eigen test, want juist daar is een bestand dat er correct uitziet stilzwijgend niet het bestand dat wordt gebruikt. Vergelijk de onderhandelde toestand met de intentie die in het profiel is vastgelegd, want slechts één van beide is in een log zichtbaar.

Kies een beleid en verifieer dan het onderhandelde resultaat

Kies strikte weigering wanneer u beide kanten kunt wijzigen, asymmetrische acceptatie wanneer dat nog niet kan, en volledige compressie alleen wanneer u kunt uitleggen waarom de blootstelling aanvaardbaar is. Verifieer daarna wat is onderhandeld in plaats van wat het bestand zegt. Een stiller log is alleen bewijs wanneer het overeenkomt met het beleid dat u wilde uitrollen.

Houd de beslissing naast het profiel waarop die van toepassing is, met de datum en de peers die nog zijn vrijgesteld. Een half jaar later is die notitie het verschil tussen een bewuste uitzondering en een ongeval dat niemand kan dateren. Schrijf haar in dezelfde repository als het profiel, zodat de volgende bewerker de reden vóór de richtlijn ziet.