Mrtvý listener OpenVPN 2.5 na DD-WRT? Přečtěte si vygenerovanou konfiguraci

Mrtvý listener na DD-WRT obvykle znamená, že démon skončil při parsování své konfigurace, ne že pravidlo firewallu zablokovalo port. OpenVPN 2.5 zpřísnil několik výchozích hodnot, na které se starší konfigurace spoléhaly, a vygenerovaná konfigurace, která fungovala na starším buildu, může být odmítnuta dřív, než se socket vůbec otevře. Důvod najdete ve vlastním logu routeru a vstup ve vygenerovaném souboru. Číst obojí v tomto pořadí je rychlejší než jakýkoli odchyt paketů.

Démon není firewall

Rozdíl je důležitý, protože zvenčí obě selhání vypadají stejně: klient pošle handshake a nic nedostane. Jedno je proces, který neběží, a druhé je proces, který běží a filtruje.

Oddělte je dvěma kontrolami, než cokoli změníte, protože úprava firewallu na mrtvém démonovi jen přidá druhou proměnnou.

Přečtěte si konfiguraci, kterou DD-WRT vygeneroval

DD-WRT nepředává OpenVPN text, který jste napsali do webového rozhraní. Zapíše vygenerovanou konfiguraci do /tmp/openvpn/openvpn.conf a spustí démona s tímto souborem, takže pole rozhraní a jakýkoli text v Additional Config se sloučí dřív, než je OpenVPN vůbec uvidí. Pokud ladíte formulář místo vygenerovaného souboru, čtete záměr, ne skutečný vstup. Zkopírujte ten soubor na trvalé místo, než restart /tmp vymaže.

Porovnejte vygenerovaný soubor s tím, co jste zamýšleli, zejména tam, kde rozhraní zapisuje direktivu, kterou jste nikdy nezvolili. Rozbalovací nabídka, která vydává zastaralou volbu, je ve formuláři neviditelná a pro démona smrtelná.

Pokud je vygenerovaný soubor prázdný nebo chybí, démon se vůbec nedostal ke startu a problém je nad OpenVPN.

Co OpenVPN 2.5 přestal přijímat

OpenVPN 2.5 nahradil ncp-ciphers za data-ciphers, a zvedl výchozí minimální verzi TLS na 1.2. Změnil také zpracování komprese, takže protějšek, který nabízí kompresi, je odmítnut, pokud to konfigurace výslovně nepovolí, a označil za zastaralé starší názvy voleb, jako je ns-cert-type ve prospěch remote-cert-tls. Každá z těchto změn mění dříve funkční konfiguraci v selhání parsování nebo vyjednávání.

Režim selhání závisí na direktivě. Neznámá nebo odstraněná volba zastaví démona při startu, to je váš mrtvý listener. Nesoulad při vyjednávání nechá démona běžet a odmítá klienty, což z klientské strany vypadá jako problém firewallu.

Čtěte první chybu v logu, ne poslední. Parsování se zastaví na první špatné direktivě a všechno po ní je šum z ukončení.

Předpoklady specifické pro Broadcom

Na buildech pro Broadcom musí tunelové zařízení existovat dřív, než ho démon může použít. Zkontrolujte, že je modul tun načtený a že /dev/net/tun existuje, protože chybějící zařízení způsobí selhání startu, které nemá nic společného s certifikáty. Totéž platí pro pomocné skripty, které DD-WRT generuje pro trasy a DNS: pokud chybí nebo nejsou spustitelné, démon může nastartovat a přesto nedokončit své nastavení.

Spusťte démona na popředí s vyšší podrobností nad vygenerovanou konfigurací, když potřebujete skutečnou zprávu. Běh na popředí vypíše chybu parsování, kterou init skript spolkl.

Pak obnovte běžnou službu, protože démon na popředí a init skript se budou přetahovat o port.

Dokažte, že listener existuje, než začnete ladit klienty

Potvrďte proces a socket odděleně: jeden příkaz pro běžícího démona, druhý pro navázaný UDP port na očekávané adrese. Proces bez socketu znamená, že je ještě v nastavení nebo navázaný na špatné rozhraní. Ta dvojice je užitečný test právě proto, že jedna polovina nemůže platit bez druhé.

Ladění na straně klienta má smysl až poté, co listener existuje. Pak zkontrolujte, že šifra a nastavení TLS klienta odpovídají data-ciphers serveru a jeho minimální verzi, a že port je skutečně přesměrován na router.

Uchovejte vygenerovanou konfiguraci a řádek logu, který opravu prokázal. Příští aktualizace firmwaru může výchozí hodnoty znovu změnit a právě tento záznam mění opakování v pětiminutovou kontrolu.