Proč přidání opt-verify neopraví chybu šifry v OpenVPN

Najdete radu přidat opt-verify, řádek přidáte a chyba šifry zůstane přesně tam, kde byla. Takový výsledek je předvídatelný, protože volba nikdy nevyjednávala šifru. Byla to kontrola konzistence voleb, zastaralá ve 2.6 a odstraněná ve 2.7, a profil, který se s ní stále parsuje, tím nic nevynutil.

Pomáhá vědět, co řádek dříve dělal, než usoudíte, že je to chybějící dílek. Historie také vysvětluje, proč teď nemůže pomoci.

Co volba dříve vynucovala

Příručka pro 2.6 označuje opt-verify jako zastaralou a popisuje dřívější chování: server zahazuje klienty, jejichž deklarované volby neodpovídají jeho vlastním, a porovnává věci jako typ zařízení a MTU. Tato kontrola také závisí na tom, že kontrola konzistence voleb zůstane zapnutá, takže server běžící s disable-occ ji nikdy neměl. Všimněte si, z čeho je porovnání postaveno: z textu popisujícího konfiguraci protějšku. Neříká nic o tom, kterou šifru bude datový kanál používat.

To je první důvod, proč přepínač nemůže opravit chybu šifry. Výběr šifry se řídí politikou data-ciphers a tím, co obě strany podporují, a textová kontrola konzistence tento seznam nerozšiřuje ani neprovádí vyjednávání. Druhým důvodem je rozsah: kontrola se týká toho, zda deklarované volby vypadají kompatibilně, ne kvality cesty, která z toho vznikne.

Co dělá 2.7, když ten řádek uvidí

Ve 2.7 volba není. Parser stále rozpoznává název, proto se starý profil načte bez syntaktické chyby, a hlásí, že volba byla odstraněna, místo aby ji mlčky přešel. Rozpoznat název a vynutit chování jsou různé věci a nyní se děje jen to první. Poznámky k odstranění uvádějí důvod: jakmile lze o parametrech vyjednávat, dvě strany mohou legitimně mít různé řetězce voleb, i když se na připojení shodnou.

Profil, který se parsuje, tedy není důkazem, že proběhla jakákoli vstupní kontrola. Pokud je vaším jediným signálem to, že se klient připojil, dozvěděli jste se, že syntaxe byla přijata.

Kde selhání skutečně sídlí

Zachovejte první konkrétní chybu, než cokoli změníte, protože pozdější zprávy jsou obvykle jejími důsledky. Selhání vyjednávání datového kanálu patří ke schválené politice šifer a k možnostem, které obě strany skutečně inzerují. Selhání verze nebo sady TLS patří ke kontrolnímu kanálu. Odmítnutí certifikátu potřebuje identitu a řetězec důvěry, ne přepínač kompatibility.

Určete také engine na obou koncích. Desktopová aplikace může obsahovat jiné sestavení než příkazový binární soubor, se kterým jste testovali, a podpora voleb se mezi nimi liší. Podívejte se do dokumentace onoho enginu, místo abyste předpokládali, že každý program, který importuje profil, se chová stejně.

Nahraďte záměr, ne jen řádek

Pokud se starší spravovaný server skutečně spoléhal na kontrolu konzistence, poznamenejte si, jaké omezení vynucoval před upgradem. Ponechání ignorované volby v novějším profilu tuto politiku nezachová a bezhlavé mazání řádků také ne.

Nereagujte na starou radu, že všechny šifry jsou zakázané, tím, že povolíte každý historický algoritmus.

Po schválené opravě prohlédněte vyjednané výsledky na novém připojení a otestujte aplikaci, kterou uživatel skutečně potřebuje. Mějte verzi serveru a efektivní politiku vedle tohoto výsledku, aby další člověk viděl, na čem se dohodli, a ne jen co bylo přijato.

Cílem je podporované omezení a fungující ověřená cesta, ne starý přepínač, který se stále parsuje.