OpenVPN-tömörítés: elutasítás, csak fogadás vagy teljes LZO?
A comp-lzo no nem szigorú elutasítás. Hasonlítsa össze a tömörítés elutasítását, a migráció alatti egyirányú elfogadást és a megtartást, majd nézze meg, mit tesz az offload.
Egy profilban három sor mind úgy tűnik, mintha kikapcsolná a tömörítést, és közülük csak egy teszi ezt valóban. A különbség számít, mert az a figyelmeztetés, amelyet el akar csendesíteni, tünet, míg a szabályzat dönti el, hogy a másik fél még tömöríthet-e. A lehetőségek egyetlen tengelyen való összevetése, azaz hogy melyik mit engedélyez a változás után, megszünteti a bizonytalanság nagy részét. Hogy melyiket akarja, attól függ, migrál-e vagy letelepszik.
Három szabályzat, amely a konfigurációs fájlban hasonlónak látszik
Minden lehetőség más kérdésre válaszol. A allow-compression no azonnal elutasítja a tömörített hasznos terhelést, a allow-compression asym kicsomagolja, ami érkezik, és soha nem tömöríti, ami elmegy, a régi comp-lzo no pedig helyet hagy a másik fél push-jának a tömörítés bekapcsolására. Csak az első olyan szabályzat, amelyet egy kiszolgáló nem tud felülírni.
Választás előtt írja be a hármat egy táblázatba, mert a nevek elég közel állnak egymáshoz ahhoz, hogy félrevezessenek egy ellenőrt. Közülük kettő még mindig kicsomagoló kódot futtat a fogadott csomagokon, és a biztonsági érv éppen erről szól. A harmadik eltávolítja a képességet, ahelyett hogy korlátozná annak irányát. Ha a változási jegyzőkönyv azt mondja, hogy a tömörítés ki van kapcsolva, pontosan egy sor felel meg ennek a mondatnak.
A vizsgálatot elindító figyelmeztetés nem a cél. Elcsendesítése, miközben egy megengedő szabályzat a helyén marad, tiszta naplót és változatlan kitettséget eredményez.
| 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 |
Mit jelent a no a régi LZO lehetőségnél
Az elavult LZO lehetőségnél a no kikapcsolja a tömörítést a helyi oldalon, anélkül hogy megtiltaná a másik félnek, hogy bekapcsolja ott, ahol a szabályzat engedi. Ez az aszimmetria az oka annak, hogy egy profil szigorú elutasításra váltása olyan módon változtatja meg a viselkedést, amelyet egyetlen kiszolgálós laboratóriumi teszt talán soha nem tár fel.
A biztonsági aggodalom feltételes, nem abszolút. Amikor egy támadó választott nyílt szöveget helyezhet egy titok mellé, és figyelheti, hogyan változtatja meg a tömörítés a titkosított forgalom méretét, információs csatorna létezik. Az LZO-ról LZ4-re váltás az algoritmust és a keretezést változtatja meg, nem ezt a mechanizmust.
A tisztességes keretezés tehát arról szól, mit hajlandó engedélyezni, nem arról, melyik algoritmus ajánlott éppen. A szigorú elutasítás az egyetlen lehetőség, amely nem függ a másik fél együttműködésétől.
A csak fogadás migrációs állapot, nem célállomás
Az aszimmetrikus elfogadás azért létezik, hogy az egyik fél abbahagyhassa a tömörítést, miközben a másik még számít rá. Ez egy híd, a hidaknak pedig végdátumra és felelősre van szükségük. Jegyezze fel, mely partnerek küldenek még tömörített forgalmat, mert a szabályzat éppen azt a forgalmat engedélyezi. E lista nélkül a migrációs állapot tehetetlenségből állandó konfigurációvá válik.
Egy ügyfél nem kényszeríthet egy nem kompatibilis kiszolgálót a régi keretezés elhagyására a saját fájlja szerkesztésével. A push irányát a kiszolgáló dönti el, tehát a migráció valójában a kiszolgáló konfigurációjában és az ügyfelenkénti fájljaiban fejeződik be.
A stub módok megőrzik a keretezést, miközben kihagyják magát a tömörítési munkát, és nem közvetlen megfelelői a régebbi lehetőségnek. Tesztelje őket a legrégebbi partnerrel szemben, amelyet még támogatnia kell, mielőtt egyik mellett dönt.
Ahol az adatcsatorna offloadja megváltoztatja a választ
Az adatcsatorna offloadja a csomagkezelést a kernelbe helyezi, és egy profil, amely még a tömörítési keretezéstől függ, talán nem illeszkedik ehhez az útvonalhoz. A hiba nem mindig hangos: az ügyfél csatlakozik, majd másként viselkedik, mint a tesztelt alagút.
Ellenőrizze, melyik megvalósítás aktív a változás előtt és után, ne csak azt, hogy sikerül-e a kapcsolat. Amikor az offloados útvonal elutasítja a tömörítési keretezést, a szigorú elutasítási szabályzat és az offloados telepítés egyetértenek, míg a megengedő szabályzat és az offloados telepítés nem.
Ez a kombináció saját tesztet érdemel, mert éppen ott történik meg, hogy egy helyesnek látszó fájl csendben nem az, amelyet használnak. Hasonlítsa össze a kialkudott állapotot a profilban rögzített szándékkal, mert közülük csak az egyik látható egy naplóban.
Válasszon szabályzatot, majd ellenőrizze a kialkudott eredményt
Válasszon szigorú elutasítást, amikor mindkét végét módosíthatja, aszimmetrikus elfogadást, amikor még nem, és teljes tömörítést csak akkor, amikor meg tudja indokolni, miért elfogadható a kitettség. Utána azt ellenőrizze, amit kialkudtak, ne azt, amit a fájl mond. A csendesebb napló csak akkor bizonyíték, ha egyezik a szabályzattal, amelyet telepíteni szándékozott.
Tartsa a döntést az érintett profil mellett, a dátummal és a még mentesített partnerekkel. Fél év múlva ez a feljegyzés a különbség egy szándékos kivétel és egy olyan baleset között, amelyet senki sem tud dátumozni. Ugyanabban a tárolóban írja le, mint a profilt, hogy a következő szerkesztő az utasítás előtt lássa az okot.