DD-WRT OpenVPN 2.5-lyssnaren död? Läs konfigurationen den genererade

En död lyssnare på DD-WRT betyder oftast att daemonen avslutades när den parsade sin konfiguration, inte att en brandväggsregel blockerade porten. OpenVPN 2.5 har stramat åt flera standardvärden som äldre konfigurationer förlitade sig på, och en genererad konfiguration som fungerade på ett äldre bygge kan avvisas innan socketen ens öppnas. Orsaken finns i routerns egen logg och indata i den genererade filen. Att läsa båda i den ordningen går snabbare än någon paketinsamling.

Daemonen är inte brandväggen

Skillnaden spelar roll eftersom de två felen ser likadana ut utifrån: en klient skickar en handskakning och får ingenting tillbaka. Det ena är en process som inte körs, det andra är en process som körs och filtrerar.

Separera dem med två kontroller innan du ändrar något, för en brandväggsändring på en död daemon lägger bara till en andra variabel.

Läs konfigurationen som DD-WRT genererade

DD-WRT ger inte OpenVPN texten du skrev i webbgränssnittet. Det skriver en genererad konfiguration till /tmp/openvpn/openvpn.conf och startar daemonen med den filen, så gränssnittets fält och all text i Additional Config slås samman innan OpenVPN ens ser dem. Om du felsöker formuläret i stället för den genererade filen läser du en avsikt och inte den faktiska indatan. Kopiera filen till en beständig plats innan en omstart /tmp tömmer den.

Jämför den genererade filen med det du avsåg, särskilt där gränssnittet skriver ett direktiv som du aldrig valde. En rullgardinsmeny som skickar ut ett föråldrat alternativ är osynlig i formuläret och dödlig för daemonen.

Om den genererade filen är tom eller saknas nådde daemonen inte ens starten, och problemet ligger före OpenVPN.

Vad OpenVPN 2.5 slutade acceptera

OpenVPN 2.5 ersatte ncp-ciphers med data-ciphers, och höjde den minsta TLS-versionen som standard till 1.2. Det ändrade också hanteringen av komprimering, så att en part som erbjuder komprimering avvisas om inte konfigurationen uttryckligen tillåter det, och det markerade äldre alternativnamn som ns-cert-type som föråldrade till förmån för remote-cert-tls. Var och en av dessa ändringar gör en tidigare fungerande konfiguration till ett parsnings- eller förhandlingsfel.

Feilläget beror på direktivet. Ett okänt eller borttaget alternativ stoppar daemonen vid start, det är din döda lyssnare. En avvikelse i förhandlingen låter daemonen köra och avvisar klienter, vilket från klientsidan ser ut som ett brandväggsproblem.

Läs det första felet i loggen, inte det sista. Parsningen stannar vid det första dåliga direktivet, och allt efter det är brus från avstängningen.

Förutsättningarna som är specifika för Broadcom

På Broadcom-byggen måste tunnelenheten finnas innan daemonen kan använda den. Kontrollera att tun-modulen är laddad och att /dev/net/tun finns, eftersom en saknad enhet ger ett startfel som inte har något med certifikat att göra. Detsamma gäller hjälpscripten som DD-WRT genererar för rutter och DNS: om de saknas eller inte är körbara kan daemonen starta och ändå inte slutföra sin konfiguration.

Kör daemonen i förgrunden med högre detaljnivå mot den genererade konfigurationen när du behöver det riktiga meddelandet. En förgrundskörning skriver ut parsningsfelet som init-skriptet svalde.

Återställ sedan den normala tjänsten, för en förgrundsdaemon och init-skriptet kommer att slåss om porten.

Bevisa att lyssnaren finns innan du felsöker klienter

Bekräfta processen och socketen var för sig: ett kommando för den körande daemonen, ett annat för en bunden UDP-port på den förväntade adressen. En process utan socket betyder att den fortfarande är under konfiguration eller bunden till fel gränssnitt. Paret är ett användbart test just eftersom den ena halvan inte kan vara sann utan den andra.

Felsökning på klientsidan är bara meningsfull när lyssnaren finns. Kontrollera då att klientens chiffer och TLS-inställningar stämmer med serverns data-ciphers lista och minsta version, och att porten verkligen vidarebefordras till routern.

Spara den genererade konfigurationen och loggraden som bevisade rättelsen. Nästa firmwareuppdatering kan ändra standardvärdena igen, och den registreringen är det som gör en upprepning till en femminuterskontroll.