Hvorfor det ikke hjelper å legge til opt-verify for å fikse OpenVPN-chifferfeilen

Du finner et forslag om å legge til opt-verify, legger inn linjen, og chifferfeilen står nøyaktig der den sto. Det utfallet er forutsigbart, fordi alternativet aldri forhandlet fram en chiffer. Det var en kontroll av alternativsamsvar, avviklet i 2.6 og fjernet i 2.7, og en profil som fortsatt parses med det, har ikke dermed håndhevet noe.

Det hjelper å vite hva linjen pleide å gjøre før du konkluderer med at den er den manglende brikken. Historikken forklarer også hvorfor den ikke kan hjelpe nå.

Hva alternativet pleide å håndheve

2.6-håndboken markerer opt-verify som avviklet og beskriver den tidligere oppførselen: serveren forkaster klienter hvis oppgitte alternativer ikke samsvarer med dens egne, ved å sammenligne ting som enhetstype og MTU. Den kontrollen avhenger også av at kontrollen av alternativsamsvar forblir aktivert, så en server som kjører med disable-occ, har aldri hatt den. Legg merke til hva sammenligningen bygges på: tekst som beskriver en motparts konfigurasjon. Den sier ingenting om hvilken chiffer datakanalen vil bruke.

Det er den første grunnen til at flagget ikke kan reparere en chifferfeil. Chiffersvalg styres av data-ciphers-policyen og av hva begge parter støtter, og en tekstlig samsvarskontroll verken utvider den listen eller utfører forhandlingen. En andre grunn er omfanget: kontrollen handler om hvorvidt oppgitte alternativer ser kompatible ut, ikke om kvaliteten på banen som blir resultatet.

Hva 2.7 gjør når den ser linjen

I 2.7 er alternativet borte. Parseren gjenkjenner fortsatt navnet, og derfor lastes en gammel profil uten syntaksfeil, og den rapporterer at alternativet ble fjernet i stedet for å gå stille forbi det. Å gjenkjenne et navn og å håndheve en oppførsel er forskjellige ting, og bare det første skjer fortsatt. Fjerningsnotatene oppgir grunnen: når parametere først kan forhandles, kan to parter med rette ha forskjellige alternativstrenger mens de er enige om tilkoblingen.

En profil som parses er derfor ikke bevis på at noen adgangskontroll ble kjørt. Hvis det eneste signalet ditt er at klienten koblet til, har du lært at syntaksen ble godtatt.

Hvor feilen faktisk ligger

Ta vare på den første konkrete feilen før du endrer noe, fordi senere meldinger vanligvis er konsekvenser av den. En forhandlingsfeil i datakanalen hører til den godkjente chifferpolicyen og til egenskapene begge parter faktisk annonserer. En feil i TLS-versjon eller -suite hører til kontrollkanalen. En sertifikatavvisning trenger identiteten og tillitskjeden, ikke et kompatibilitetsflagg.

Identifiser også motoren i begge ender. En skrivebordsapplikasjon kan pakke en annen bygg enn kommandolinjebinæren du testet med, og alternativstøtten varierer mellom dem. Sjekk dokumentasjonen til den motoren i stedet for å anta at alle programmer som importerer en profil, oppfører seg likt.

Erstatt intensjonen, ikke bare linjen

Hvis en eldre administrert server virkelig var avhengig av samsvarskontrollen, noter hvilken begrensning den håndhevet før oppgraderingen. Å beholde et ignorert alternativ i en nyere profil kan ikke bevare den policyen, og å slette linjer vilkårlig kan heller ikke.

Ikke svar på et gammelt forslag om at alle chiffere er deaktivert ved å aktivere hver historisk algoritme.

Etter en godkjent korreksjon, inspiser de forhandlede resultatene på en ny tilkobling og test applikasjonen brukeren faktisk trenger. Hold serverversjonen og den effektive policyen ved siden av resultatet, slik at neste person kan se hva som ble avtalt i stedet for hva som bare ble godtatt.

Målet er en støttet begrensning og en fungerende autentisert bane, ikke et arvet flagg som fortsatt parses.