OpenVPN-pakkaus: kieltäydy, vastaanota vain vai täysi LZO?
comp-lzo no ei ole ehdoton kieltäytyminen. Vertaa pakkauksesta kieltäytymistä, yksisuuntaista hyväksymistä siirtymän aikana ja sen säilyttämistä, ja tarkista sitten, mitä offload tekee.
Kolme profiilin riviä näyttävät kaikki kytkevän pakkauksen pois, ja vain yksi niistä tekee sen todella. Ero on merkittävä, koska varoitus, jonka haluat vaientaa, on oire, kun taas käytäntö ratkaisee, voiko vastapuoli yhä pakata. Vaihtoehtojen vertailu yhdellä akselilla, eli mitä kukin sallii muutoksen jälkeen, poistaa suurimman osan epäselvyydestä. Kumpaa haluat, riippuu siitä, oletko siirtymässä vai asettumassa.
Kolme käytäntöä, jotka näyttävät samanlaisilta asetustiedostossa
Jokainen vaihtoehto vastaa eri kysymykseen. allow-compression no hylkää pakatut hyötykuormat suoraan, allow-compression asym purkaa saapuvan ja jättää aina lähtevän pakkaamatta, ja vanha comp-lzo no jättää tilaa vastapuolen pushille pakkauksen käynnistämiseksi. Vain ensimmäinen on käytäntö, jota palvelin ei voi ohittaa.
Kirjoita ne kolme taulukkoon ennen valintaa, sillä nimet ovat tarpeeksi lähellä johtaakseen arvioijan harhaan. Kaksi niistä suorittaa yhä purkukoodia vastaanotetuille paketeille, ja juuri siitä turvallisuusargumentissa on kyse. Kolmas poistaa kyvyn sen sijaan, että rajoittaisi sen suuntaa. Jos muutoskirjaus sanoo pakkauksen olevan pois päältä, täsmälleen yksi rivi täyttää tuon lauseen.
Varoitus, joka tutkinnan aloitti, ei ole tavoite. Sen vaientaminen sallivan käytännön jäädessä voimaan antaa siistin lokin ja ennallaan pysyvän altistuksen.
| 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ä no tarkoittaa vanhassa LZO-vaihtoehdossa
Vanhentuneessa LZO-vaihtoehdossa no kytkee pakkauksen pois paikalliselta puolelta estämättä vastapuolta kytkemästä sitä päälle siellä, missä käytäntö sen sallii. Tämän epäsymmetrian vuoksi profiilin siirtäminen ehdottomaan kieltäytymiseen muuttaa käyttäytymistä tavalla, jota yhden palvelimen laboratoriokoe ei välttämättä koskaan paljasta.
Turvahuoli on ehdollinen, ei absoluuttinen. Kun hyökkääjä voi sijoittaa valitsemansa selkokielisen tekstin salaisuuden viereen ja seurata, miten pakkaus muuttaa salatun liikenteen kokoa, tiedotuskanava on olemassa. Siirtyminen LZO:sta LZ4:ään muuttaa algoritmin ja kehystyksen, ei tuota mekanismia.
Rehellinen kehys koskee siis sitä, mitä olet valmis sallimaan, ei sitä, mitä algoritmia tällä hetkellä suositellaan. Ehdoton kieltäytyminen on ainoa vaihtoehto, joka ei riipu toisen osapuolen yhteistyöstä.
Vain vastaanotto on siirtymätila, ei päämäärä
Epäsymmetrinen hyväksyminen on olemassa, jotta toinen puoli voi lopettaa pakkaamisen toisen yhä odottaessa sitä. Se on silta, ja sillat tarvitsevat päättymispäivän ja omistajan. Kirjaa, mitkä vastapuolet lähettävät yhä pakattua liikennettä, koska käytäntö sallii juuri sellaisen liikenteen. Ilman tuota luetteloa siirtymätilasta tulee pysyvä asetustila inertiaan vedoten.
Asiakasohjelma ei voi pakottaa yhteensopimatonta palvelinta luopumaan vanhasta kehystyksestä muokkaamalla omaa tiedostoaan. Pushin suunta päätetään palvelimella, joten siirtymä todella päättyy palvelimen asetuksiin ja sen asiakaskohtaisiin tiedostoihin.
Stub-tilat säilyttävät kehystyksen mutta ohittavat itse pakkaustyön, eivätkä ne ole vanhemman vaihtoehdon suora vastine. Testaa niitä vanhinta vastapuolta vasten, jota sinun vielä on tuettava, ennen kuin sitoudut yhteen.
Missä datakanavan offload muuttaa vastausta
Datakanavan offload siirtää pakettien käsittelyn ytimeen, eikä profiili, joka yhä riippuu pakkauksen kehystyksestä, välttämättä sovi offload-polulle. Epäonnistuminen ei aina ole äänekästä: asiakasohjelma yhdistää ja käyttäytyy sitten eri tavalla kuin testaamasi tunneli.
Tarkista, mikä toteutus on aktiivinen ennen muutosta ja sen jälkeen, ei vain sitä, onnistuuko yhteys. Kun offload-polku hylkää pakkauksen kehystyksen, ehdoton kieltäytymiskäytäntö ja offload-käyttöönotto ovat sopusoinnussa, kun taas salliva käytäntö ja offload-käyttöönotto eivät ole.
Tuo yhdistelmä ansaitsee oman kokeensa, sillä juuri siinä oikealta näyttävä tiedosto ei hiljaa olekaan se, jota käytetään. Vertaa neuvoteltua tilaa profiiliin kirjattuun aikomukseen, koska vain toinen niistä näkyy lokissa.
Valitse käytäntö ja varmista sitten neuvoteltu tulos
Valitse ehdoton kieltäytyminen, kun voit muuttaa molemmat päät, epäsymmetrinen hyväksyminen, kun et vielä voi, ja täysi pakkaus vain silloin, kun voit perustella, miksi altistus on hyväksyttävää. Varmista sitten, mitä neuvoteltiin, eikä sitä, mitä tiedosto sanoo. Vaimeampi loki on todiste vain silloin, kun se vastaa käytäntöä, jonka aioit ottaa käyttöön.
Pidä päätös sen profiilin vieressä, jota se koskee, yhdessä päivämäärän ja yhä vapautettujen vastapuolten kanssa. Puolen vuoden päästä tuo merkintä on ero tarkoituksellisen poikkeuksen ja onnettomuuden välillä, jota kukaan ei osaa ajoittaa. Kirjoita se samaan tietovarastoon kuin profiili, jotta seuraava muokkaaja näkee syyn ennen direktiiviä.