OpenVPN-kompakto: rifuzi, nur ricevi aŭ plena LZO?
comp-lzo no ne estas strikta rifuzo. Komparu rifuzon de kompakto, unuflankan akcepton dum migrado kaj ties konservon, poste kontrolu, kion faras offload.
Tri linioj en profilo aspektas kvazaŭ ĉiuj malŝaltus kompakton, sed nur unu el ili vere faras tion. La diferenco gravas, ĉar la averto, kiun vi volas silentigi, estas simptomo, dum la politiko decidas, ĉu la kontraŭa flanko ankoraŭ povas kompaki. Komparo de la opcioj laŭ unu akso, nome kion ĉiu permesas post la ŝanĝo, forigas la plej grandan parton de la malklaro. Kiun vi volas, dependas de tio, ĉu vi migras aŭ enloĝiĝas.
Tri politikoj, kiuj en agorda dosiero aspektas similaj
Ĉiu opcio respondas al malsama demando. allow-compression no rifuzas kunpremitajn utilajn ŝarĝojn tute, allow-compression asym malkompaktigas tion, kio alvenas, kaj neniam kunpremas tion, kio foriras, kaj la malnova comp-lzo no lasas lokon por puŝo de la kontraŭa flanko ŝalti kunpremadon. Nur la unua estas politiko, kiun servilo ne povas superregi.
Skribu la tri en tabelon antaŭ ol elekti, ĉar la nomoj estas sufiĉe proksimaj por misgvidi recenzanton. Du el ili ankoraŭ rulas malkompaktan kodon sur ricevitaj pakaĵoj, kaj ĝuste pri tio temas la sekureca argumento. La tria forigas la kapablon anstataŭ limigi ĝian direkton. Se la ŝanĝprotokolo diras, ke kompakto estas malŝaltita, ekzakte unu vico plenumas tiun frazon.
La averto, kiu komencis la esploron, ne estas la celo. Silenti ĝin dum permesema politiko restas, donas puran protokolon kaj neŝanĝitan ekspozicion.
| 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 |
Kion no signifas ĉe la malnova LZO-opcio
Ĉe la eksmodiĝinta LZO-opcio, no malŝaltas kompakton por la loka flanko sen malpermesi al la kontraŭa flanko ŝalti ĝin tie, kie la politiko permesas. Pro tiu asimetrio, movi profilon al strikta rifuzo ŝanĝas la konduton tiel, kiel unu-servila laboratoria testo eble neniam malkovros.
La sekureca zorgo estas kondiĉa, ne absoluta. Kiam atakanto povas meti elektitan klartekston apud sekreton kaj observi, kiel kompakto ŝanĝas la grandecon de ĉifrita trafiko, ekzistas informa kanalo. La transiro de LZO al LZ4 ŝanĝas la algoritmon kaj la kadrigon, ne tiun mekanismon.
La honesta kadro do temas pri tio, kion vi pretas permesi, ne pri tio, kiu algoritmo estas nuntempe rekomendata. Strikta rifuzo estas la sola opcio, kiu ne dependas de kunlaboro de la alia flanko.
Nur-ricevo estas migra stato, ne celo
Unuflanka akcepto ekzistas por ke unu flanko povu ĉesi kompaki, dum la alia ankoraŭ atendas tion. Ĝi estas ponto, kaj pontoj bezonas finan daton kaj posedanton. Notu, kiuj partneroj ankoraŭ sendas kunpremitan trafikon, ĉar la politiko permesas ĝuste tian trafikon. Sen tiu listo, la migra stato fariĝas la permanenta agordo pro inercio.
Kliento ne povas devigi malkongruan servilon forlasi la malnovan kadrigon per redaktado de sia propra dosiero. La puŝa direkto decidiĝas sur la servilo, do la migrado efektive finiĝas en la servila agordo kaj ĝiaj dosieroj por ĉiu kliento.
Stub-reĝimoj konservas la kadrigon dum ili saltas la kompaktan laboron mem, kaj ili ne estas rekta ekvivalento de la pli malnova opcio. Testu ilin kontraŭ la plej malnova partnero, kiun vi ankoraŭ devas subteni, antaŭ ol decidiĝi pri unu.
Kie offload de la datumkanalo ŝanĝas la respondon
Offload de la datumkanalo movas pakaĵan traktadon en la kernon, kaj profilo, kiu ankoraŭ dependas de kompakta kadrigo, eble ne taŭgas por tiu vojo. La malsukceso ne ĉiam laŭtas: kliento konektiĝas kaj poste kondutas alie ol la tunelo, kiun vi testis.
Kontrolu, kiu efektivigo estas aktiva antaŭ kaj post la ŝanĝo, ne nur ĉu la konekto sukcesas. Kiam la offload-vojo rifuzas kompaktan kadrigon, strikta rifuzpolitiko kaj offload-ekspluatado konsentas, dum permesema politiko kaj offload-ekspluatado ne konsentas.
Tiu kombino meritas propran teston, ĉar ĝuste tie dosiero, kiu aspektas ĝusta, silente ne estas tiu, kiu estas uzata. Komparu la intertraktitan staton kun la intenco registrita en la profilo, ĉar nur unu el ili videblas en protokolo.
Elektu politikon, poste kontrolu la intertraktitan rezulton
Elektu striktan rifuzon, kiam vi povas ŝanĝi ambaŭ flankojn, unuflankan akcepton, kiam vi ankoraŭ ne povas, kaj plenan kompakton nur kiam vi povas klarigi, kial la ekspozicio estas akceptebla. Poste kontrolu, kio estis intertraktita, anstataŭ kion diras la dosiero. Pli trankvila protokolo estas pruvo nur kiam ĝi kongruas kun la politiko, kiun vi intencis apliki.
Tenu la decidon apud la profilo, al kiu ĝi rilatas, kun la dato kaj la partneroj ankoraŭ esceptitaj. Duonjaron poste, tiu noto estas la diferenco inter intenca escepto kaj akcidento, kiun neniu povas dati. Skribu ĝin en la sama deponejo kiel la profilo, por ke la sekva redaktanto vidu la kialon antaŭ la direktivo.