Kodėl pridėjus opt-verify OpenVPN šifravimo klaida neišnyks

Radę pasiūlymą pridėti opt-verify, įterpiate eilutę, o šifravimo klaida lieka lygiai ten, kur buvo. Toks rezultatas nuspėjamas, nes parinktis niekada nedėrėjo šifravimo. Tai buvo parinkčių nuoseklumo patikra, pasenusi 2.6 versijoje ir pašalinta 2.7 versijoje, o profilis, kuris su ja vis dar analizuojamas, tuo nieko neįtvirtino.

Naudinga žinoti, ką eilutė anksčiau darė, prieš darant išvadą, kad tai yra trūkstama dalis. Istorija taip pat paaiškina, kodėl dabar ji negali padėti.

Ką parinktis anksčiau įtvirtino

2.6 vadove opt-verify pažymėta kaip pasenusi ir aprašomas ankstesnis elgesys: serveris atmeta klientus, kurių deklaruotos parinktys nesutampa su jo paties, lygindamas tokius dalykus kaip įrenginio tipas ir MTU. Ši patikra taip pat priklauso nuo to, ar parinkčių nuoseklumo tikrinimas lieka įjungtas, todėl serveris, veikiantis su disable-occ, niekada jos neturėjo. Atkreipkite dėmesį, iš ko sudarytas palyginimas: iš teksto, aprašančio kitos pusės konfigūraciją. Jis nieko nesako apie tai, kokį šifravimą naudos duomenų kanalas.

Tai pirmoji priežastis, kodėl vėliavėlė negali pataisyti šifravimo klaidos. Šifravimo pasirinkimą lemia data-ciphers politika ir tai, ką palaiko abi pusės, o tekstinė nuoseklumo patikra nei išplečia tą sąrašą, nei atlieka derybas. Antroji priežastis yra apimtis: patikra susijusi su tuo, ar deklaruotos parinktys atrodo suderinamos, o ne su susidariusio kelio kokybe.

Ką 2.7 daro pamatęs eilutę

2.7 versijoje parinkties nebėra. Analizatorius vis dar atpažįsta pavadinimą, todėl senas profilis įkeliamas be sintaksės klaidos, ir jis praneša, kad parinktis buvo pašalinta, o ne tyliai ją praleidžia. Atpažinti pavadinimą ir įtvirtinti elgesį yra skirtingi dalykai, ir kol kas vyksta tik pirmasis. Šalinimo pastabos nurodo priežastį: kai parametrai gali būti derėdamiesi, dvi pusės gali teisėtai turėti skirtingas parinkčių eilutes, nors ir susitaria dėl ryšio.

Todėl profilis, kuris analizuojamas, nėra įrodymas, kad buvo atlikta kokia nors priėmimo patikra. Jei vienintelis signalas yra tai, kad klientas prisijungė, sužinojote, kad sintaksė buvo priimta.

Kur iš tikrųjų glūdi gedimas

Išsaugokite pirmąją konkrečią klaidą prieš ką nors keisdami, nes vėlesni pranešimai paprastai yra jos pasekmės. Duomenų kanalo derybų gedimas priklauso patvirtintai šifravimo politikai ir galimybėms, kurias abi pusės iš tikrųjų skelbia. TLS versijos ar rinkinio gedimas priklauso valdymo kanalui. Sertifikato atmetimas reikalauja tapatybės ir pasitikėjimo grandinės, o ne suderinamumo vėliavėlės.

Nustatykite ir variklį abiejuose galuose. Darbalaukio programa gali turėti kitą kompiliavimo variantą nei komandų eilutės dvejetainis failas, su kuriuo testavote, ir parinkčių palaikymas tarp jų skiriasi. Pasidomėkite to variklio dokumentacija, o ne manykite, kad kiekviena programa, importuojanti profilį, elgiasi vienodai.

Pakeiskite ketinimą, o ne tik eilutę

Jei senesnis valdomas serveris tikrai rėmėsi nuoseklumo patikra, užsirašykite, kokį apribojimą jis įtvirtino prieš atnaujinimą. Nepaisomos parinkties palikimas naujesniame profilyje negali išsaugoti tos politikos, o beatodairiškas eilučių trynimas taip pat negali.

Neatsakykite į seną pasiūlymą, kad visi šifravimai išjungti, įjungdami kiekvieną istorinį algoritmą.

Po patvirtinto pataisymo patikrinkite suderėtus rezultatus naujame ryšyje ir išbandykite programą, kurios vartotojui tikrai reikia. Laikykite serverio versiją ir galiojančią politiką šalia to rezultato, kad kitas žmogus matytų, dėl ko susitarta, o ne tik kas buvo priimta.

Tikslas yra palaikomas apribojimas ir veikiantis autentifikuotas kelias, o ne sena vėliavėlė, kuri vis dar analizuojama.