Kvifor det å leggje til opt-verify ikkje rettar OpenVPN-sifferfeilen

Du finn eit framlegg om å leggje til opt-verify, legg inn linja, og sifferfeilen står nøyaktig der han stod. Det utfallet er føreseieleg, fordi alternativet aldri forhandla fram ein siffer. Det var ein kontroll av alternativsamsvar, avvikla i 2.6 og fjerna i 2.7, og ein profil som framleis blir parsa med det, har ikkje dermed handheva noko.

Det hjelper å vite kva linja pleidde å gjere før du konkluderer med at ho er den manglande biten. Historikken forklarer også kvifor ho ikkje kan hjelpe no.

Kva alternativet pleidde å handheve

Handboka for 2.6 merkar opt-verify som avvikla og skildrar den tidlegare åtferda: tenaren kastar ut klientar der dei oppgjevne alternativa ikkje samsvarar med hans eigne, ved å samanlikne ting som einheitstype og MTU. Den kontrollen er også avhengig av at kontrollen av alternativsamsvar blir ståande på, så ein tenar som køyrer med disable-occ, har aldri hatt han. Legg merke til kva samanlikninga er bygd av: tekst som skildrar konfigurasjonen til ein motpart. Ho seier ingenting om kva siffer datakanalen vil bruke.

Det er den første grunnen til at flagget ikkje kan reparere ein sifferfeil. Siffervalet blir styrt av data-ciphers-retningslinja og av kva begge partar støttar, og ein tekstleg samsvarskontroll verken utvidar den lista eller utfører forhandlinga. Ein annan grunn er omfanget: kontrollen handlar om dei oppgjevne alternativa ser kompatible ut, ikkje om kvaliteten på vegen som blir resultatet.

Kva 2.7 gjer når han ser linja

I 2.7 er alternativet borte. Parsaren kjenner framleis att namnet, og difor blir ein gammal profil lasta utan syntaksfeil, og han rapporterer at alternativet vart fjerna i staden for å gå stille forbi det. Å kjenne att eit namn og å handheve ei åtferd er ulike ting, og berre det første skjer framleis. Fjerningsnotata oppgir grunnen: når parameterar først kan forhandlast, kan to partar med rette ha ulike alternativstrengar medan dei er samde om tilkoplinga.

Ein profil som blir parsa er difor ikkje prov på at nokon tilgangskontroll vart køyrd. Viss det einaste signalet ditt er at klienten kopla til, har du lært at syntaksen vart godteken.

Kvar feilen faktisk ligg

Ta vare på den første konkrete feilen før du endrar noko, fordi seinare meldingar vanlegvis er konsekvensar av han. Ein forhandlingsfeil i datakanalen høyrer til den godkjende sifferretningslinja og til eigenskapane begge partar faktisk annonserer. Ein feil i TLS-versjon eller -suite høyrer til kontrollkanalen. Ei sertifikatavvising treng identiteten og tillitskjeda, ikkje eit kompatibilitetsflagg.

Identifiser også motoren i begge endar. Ein skrivebordsapplikasjon kan pakke ein annan bygg enn kommandolinjebinæren du testa med, og alternativstøtta varierer mellom dei. Sjekk dokumentasjonen til den motoren i staden for å gå ut frå at alle program som importerer ein profil, oppfører seg likt.

Erstatt intensjonen, ikkje berre linja

Viss ein eldre administrert tenar verkeleg var avhengig av samsvarskontrollen, skriv ned kva avgrensing han handheva før oppgraderinga. Å halde på eit ignorert alternativ i ein nyare profil kan ikkje ta vare på den retningslinja, og å slette linjer vilkårleg kan heller ikkje.

Ikkje svar på eit gammalt framlegg om at alle sifrar er deaktiverte ved å slå på kvar historisk algoritme.

Etter ein godkjend korreksjon, gransk dei forhandla resultata på ei ny tilkopling og test applikasjonen brukaren faktisk treng. Hald tenarversjonen og den effektive retningslinja ved sida av resultatet, slik at neste person ser kva som vart avtalt i staden for kva som berre vart godteke.

Målet er ei støtta avgrensing og ein fungerande autentisert veg, ikkje eit arva flagg som framleis blir parsa.