Prečo pridanie opt-verify neopraví chybu šifrovania v OpenVPN

Nájdete radu pridať opt-verify, riadok pridáte a chyba šifrovania zostane presne tam, kde bola. Taký výsledok je predvídateľný, pretože voľba nikdy nevyjednávala šifrovanie. Bola to kontrola konzistencie volieb, zastaraná v 2.6 a odstránená v 2.7, a profil, ktorý sa s ňou stále parsuje, tým nič nevynútil.

Pomáha vedieť, čo riadok predtým robil, skôr než usúdite, že je to chýbajúci diel. História tiež vysvetľuje, prečo teraz nemôže pomôcť.

Čo voľba predtým vynucovala

Príručka pre 2.6 označuje opt-verify ako zastaranú a opisuje predchádzajúce správanie: server zahadzuje klientov, ktorých deklarované voľby nezodpovedajú jeho vlastným, a porovnáva veci ako typ zariadenia a MTU. Táto kontrola tiež závisí od toho, aby kontrola konzistencie volieb zostala zapnutá, takže server bežiaci s disable-occ ju nikdy nemal. Všimnite si, z čoho je porovnanie postavené: z textu opisujúceho konfiguráciu protistrany. Nehovorí nič o tom, ktoré šifrovanie bude dátový kanál používať.

To je prvý dôvod, prečo prepínač nemôže opraviť chybu šifrovania. Výber šifrovania sa riadi politikou data-ciphers a tým, čo obe strany podporujú, a textová kontrola konzistencie tento zoznam nerozširuje ani nevykonáva vyjednávanie. Druhým dôvodom je rozsah: kontrola sa týka toho, či deklarované voľby vyzerajú kompatibilne, nie kvality výslednej cesty.

Čo robí 2.7, keď ten riadok uvidí

V 2.7 voľba nie je. Parser stále rozpoznáva názov, preto sa starý profil načíta bez syntaktickej chyby, a hlási, že voľba bola odstránená, namiesto toho, aby ju mlčky obišiel. Rozpoznať názov a vynútiť správanie sú rozdielne veci a zatiaľ sa deje len to prvé. Poznámky k odstráneniu uvádzajú dôvod: keď sa o parametroch dá vyjednávať, dve strany môžu legitímne mať rôzne reťazce volieb, hoci sa na pripojení zhodnú.

Profil, ktorý sa parsuje, teda nie je dôkazom, že prebehla akákoľvek vstupná kontrola. Ak je jediným signálom to, že sa klient pripojil, dozvedeli ste sa, že syntax bola prijatá.

Kde zlyhanie skutočne sídli

Zachovajte prvú konkrétnu chybu, skôr než čokoľvek zmeníte, pretože neskoršie správy sú zvyčajne jej dôsledkami. Zlyhanie vyjednávania dátového kanála patrí k schválenej politike šifier a k možnostiam, ktoré obe strany skutočne inzerujú. Zlyhanie verzie alebo sady TLS patrí ku kontrolnému kanálu. Odmietnutie certifikátu potrebuje identitu a reťazec dôvery, nie prepínač kompatibility.

Určite aj engine na oboch koncoch. Desktopová aplikácia môže obsahovať iné zostavenie než príkazový binárny súbor, s ktorým ste testovali, a podpora volieb sa medzi nimi líši. Pozrite si dokumentáciu toho enginu, namiesto toho, aby ste predpokladali, že každý program importujúci profil sa správa rovnako.

Nahraďte zámer, nielen riadok

Ak sa starší spravovaný server skutočne spoliehal na kontrolu konzistencie, poznamenajte si, aké obmedzenie vynucoval pred aktualizáciou. Ponechanie ignorovanej voľby v novšom profile túto politiku nezachová a bezhlavé mazanie riadkov tiež nie.

Nereagujte na starú radu, že všetky šifrovania sú zakázané, tým, že povolíte každý historický algoritmus.

Po schválenej oprave preskúmajte vyjednané výsledky na novom pripojení a otestujte aplikáciu, ktorú používateľ skutočne potrebuje. Majte verziu servera a efektívnu politiku vedľa tohto výsledku, aby ďalší človek videl, na čom sa dohodli, a nielen čo bolo prijaté.

Cieľom je podporované obmedzenie a fungujúca overená cesta, nie starý prepínač, ktorý sa stále parsuje.