Hvorfor det ikke hjælper at tilføje opt-verify for at rette OpenVPN-chifferfejlen

Du finder et forslag om at tilføje opt-verify, tilføjer linjen, og chifferfejlen står præcis, hvor den stod. Det resultat er forudsigeligt, fordi indstillingen aldrig forhandlede en chiffer. Det var en kontrol af indstillingskonsistens, forældet i 2.6 og fjernet i 2.7, og en profil, der stadig parses med den, har ikke dermed håndhævet noget.

Det hjælper at vide, hvad linjen plejede at gøre, før du konkluderer, at den er den manglende brik. Historikken forklarer også, hvorfor den ikke kan hjælpe nu.

Hvad indstillingen plejede at håndhæve

2.6-håndbogen markerer opt-verify som forældet og beskriver den tidligere adfærd: serveren dropper klienter, hvis angivne indstillinger ikke matcher dens egne, ved at sammenligne ting som enhedstype og MTU. Den kontrol afhænger også af, at kontrollen af indstillingskonsistens forbliver aktiveret, så en server, der kører med disable-occ, har aldrig haft den. Læg mærke til, hvad sammenligningen bygges af: tekst, der beskriver en modparts konfiguration. Den siger intet om, hvilken chiffer datakanalen vil bruge.

Det er den første grund til, at flaget ikke kan reparere en chifferfejl. Chiffervalg styres af data-ciphers-politikken og af, hvad begge parter understøtter, og en tekstlig konsistenskontrol hverken udvider den liste eller udfører forhandlingen. En anden grund er omfanget: kontrollen handler om, hvorvidt angivne indstillinger ser kompatible ud, ikke om kvaliteten af den vej, der bliver resultatet.

Hvad 2.7 gør, når den ser linjen

I 2.7 er indstillingen væk. Parseren genkender stadig navnet, og derfor indlæses en gammel profil uden syntaksfejl, og den rapporterer, at indstillingen blev fjernet i stedet for at gå stille forbi den. At genkende et navn og at håndhæve en adfærd er forskellige ting, og kun det første sker stadig. Fjernelsesnoterne angiver grunden: når parametre først kan forhandles, kan to parter med rette have forskellige indstillingsstrenge, mens de er enige om forbindelsen.

En profil, der parses, er derfor ikke bevis på, at nogen adgangskontrol blev kørt. Hvis dit eneste signal er, at klienten blev forbundet, har du lært, at syntaksen blev accepteret.

Hvor fejlen faktisk ligger

Bevar den første konkrete fejl, før du ændrer noget, fordi senere meddelelser normalt er konsekvenser af den. En forhandlingsfejl i datakanalen hører til den godkendte chifferpolitik og til de egenskaber, begge parter faktisk annoncerer. En fejl i TLS-version eller -suite hører til kontrolkanalen. En certifikatafvisning kræver identiteten og tillidskæden, ikke et kompatibilitetsflag.

Identificér også motoren i begge ender. En skrivebordsapplikation kan pakke et andet build end det kommandolinjebinære program, du testede med, og indstillingsunderstøttelsen er forskellig mellem dem. Slå op i den motors dokumentation i stedet for at antage, at alle programmer, der importerer en profil, opfører sig ens.

Erstat hensigten, ikke bare linjen

Hvis en ældre administreret server virkelig var afhængig af konsistenskontrollen, skal du notere, hvilken begrænsning den håndhævede før opgraderingen. At beholde en ignoreret indstilling i en nyere profil kan ikke bevare den politik, og det kan vilkårlig sletning af linjer heller ikke.

Svar ikke på et gammelt forslag om, at alle chiffer er deaktiveret, ved at aktivere hver historisk algoritme.

Efter en godkendt rettelse, undersøg de forhandlede resultater på en ny forbindelse, og test den applikation, brugeren faktisk har brug for. Hold serverversionen og den effektive politik ved siden af resultatet, så den næste person kan se, hvad der blev aftalt, i stedet for hvad der blot blev accepteret.

Målet er en understøttet begrænsning og en fungerende autentificeret vej, ikke et arvet flag, der stadig parses.