OpenVPN-kompressie: weier, net ontvang of volle LZO?
comp-lzo no is nie 'n streng weiering nie. Vergelyk die weier van kompressie, die eenrigting-aanvaarding tydens migrasie en die behoud daarvan, en kyk dan wat offload doen.
Drie reëls in 'n profiel lyk of hulle almal kompressie afskakel, en net een van hulle doen dit werklik. Die verskil maak saak, want die waarskuwing wat jy wil stilmaak, is 'n simptoom, terwyl die beleid bepaal of 'n eweknie nog kan komprimeer. Deur die opsies op een as te vergelyk, naamlik wat elkeen ná die verandering toelaat, verdwyn die meeste dubbelsinnigheid. Watter een jy wil hê, hang daarvan af of jy migreer of jou vestig.
Drie beleide wat in 'n konfigurasielêer eenders lyk
Elke opsie beantwoord 'n ander vraag. allow-compression no weier gekompakteerde vragte heeltemal, allow-compression asym dekomprimeer wat inkom en komprimeer nooit wat uitgaan nie, en die ou comp-lzo no laat ruimte vir 'n eweknie se push om kompressie te aktiveer. Net die eerste is 'n beleid wat 'n bediener nie kan oorskryf nie.
Skryf die drie in 'n tabel neer voordat jy kies, want die name is naby genoeg aan mekaar om 'n keurder te mislei. Twee van hulle voer nog steeds dekompressiekode uit op ontvangde pakkette, en dit is presies waaroor die sekuriteitsargument gaan. Die derde verwyder die vermoë eerder as om die rigting daarvan te beperk. As die veranderingsrekord sê kompressie is afgeskakel, dan is daar presies een ry wat daardie sin waar maak.
Die waarskuwing wat die ondersoek begin het, is nie die doel nie. Om dit stil te maak terwyl 'n toegeeflike beleid bly staan, lewer 'n skoon log en 'n onveranderde blootstelling.
| 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 |
Wat nee op die ou LZO-opsie beteken
Op die verouderde LZO-opsie skakel nee kompressie vir die plaaslike kant af sonder om 'n eweknie te verbied om dit te aktiveer waar die beleid dit toelaat. Dié asimmetrie is die rede waarom die skuif van 'n profiel na 'n streng weiering gedrag verander op maniere wat 'n toets met een bediener in die laboratorium nooit sal openbaar nie.
Die sekuriteitskwessie is voorwaardelik, nie absoluut nie. Wanneer 'n aanvaller gekose gewone teks langs 'n geheim kan plaas en kan sien hoe kompressie die grootte van versleutelde verkeer verander, bestaan daar 'n inligtingskanaal. Die oorskakeling van LZO na LZ4 verander die algoritme en die raamwerk, nie daardie meganisme nie.
Die eerlike raamwerk gaan dus oor wat jy bereid is om toe te laat, nie oor watter algoritme tans aanbeveel word nie. Streng weiering is die enigste opsie wat nie van die ander kant se samewerking afhang nie.
Net-ontvang is 'n migrasietoestand, nie 'n bestemming nie
Asimmetriese aanvaarding bestaan sodat die een kant kan ophou komprimeer terwyl die ander kant dit nog verwag. Dit is 'n brug, en brûe het 'n einddatum en 'n eienaar nodig. Teken aan watter eweknieë nog gekompakteerde verkeer stuur, want die beleid laat presies daardie verkeer toe. Sonder daardie lys word die migrasietoestand deur traagheid die permanente konfigurasie.
'n Kliënt kan nie 'n onversoenbare bediener dwing om ou raamwerk te laat vaar deur sy eie lêer te wysig nie. Die push-rigting word op die bediener bepaal, so die bedienerkonfigurasie en sy lêers per kliënt is waar die migrasie werklik voltooi word.
Stub-modusse bewaar die raamwerk terwyl hulle die kompressiewerk self oorslaan, en hulle is nie 'n direkte ekwivalent van die ouer opsie nie. Toets hulle teen die oudste eweknie wat jy nog moet ondersteun voordat jy by een vasbyt.
Waar data-kanaal-offlading die antwoord verander
Data-kanaal-offlading skuif pakketverwerking in die kernel in, en 'n profiel wat nog van kompressieraamwerk afhang, pas dalk nie in die afgelaaide pad nie. Die mislukking is nie altyd hardop nie: 'n kliënt verbind en tree dan anders op as die tonnel wat jy getoets het.
Kontroleer watter implementering aktief is voor en ná die verandering, nie net of die verbinding slaag nie. Wanneer die afgelaaide pad kompressieraamwerk weier, stem 'n streng weieringsbeleid en 'n afgelaaide ontplooiing ooreen, terwyl 'n toegeeflike beleid en 'n afgelaaide ontplooiing dit nie doen nie.
Daardie kombinasie verdien sy eie toets, want dit is presies waar 'n lêer wat korrek lyk, stilweg nie die een is wat gebruik word nie. Vergelyk die onderhandelde toestand met die bedoeling wat in die profiel aangeteken is, want net een van hulle is in 'n log sigbaar.
Kies 'n beleid en verifieer dan die onderhandelde resultaat
Kies streng weiering wanneer jy beide kante kan verander, asimmetriese aanvaarding wanneer jy dit nog nie kan nie, en volle kompressie net wanneer jy kan sê waarom die blootstelling aanvaarbaar is. Verifieer dan wat onderhandel is eerder as wat die lêer sê. 'n Stilller log is net bewyse wanneer dit ooreenstem met die beleid wat jy wou ontplooi.
Hou die besluit langs die profiel waarop dit van toepassing is, met die datum en die eweknieë wat nog uitgeveer word. Ses maande later is daardie nota die verskil tussen 'n doelbewuste uitsondering en 'n ongeluk wat niemand kan dateer nie. Skryf dit in dieselfde bewaarplek as die profiel sodat die volgende redigeerder die rede voor die opdrag sien.