DD-WRT OpenVPN 2.5-listener dood? Lees de configuratie die hij genereerde

Een dode listener op DD-WRT betekent meestal dat de daemon stopte tijdens het parsen van zijn configuratie, niet dat een firewallregel de poort blokkeerde. OpenVPN 2.5 heeft verschillende standaardwaarden aangescherpt waarop oudere configuraties vertrouwden, en een gegenereerde configuratie die op een oudere build werkte kan worden geweigerd voordat de socket ooit wordt geopend. De reden staat in de log van de router zelf, en de invoer staat in het gegenereerde bestand. Beide in die volgorde lezen is sneller dan welke pakketopname dan ook.

De daemon is niet de firewall

Het onderscheid is belangrijk omdat de twee storingen er van buitenaf hetzelfde uitzien: een client stuurt een handshake en krijgt niets terug. De ene is een proces dat niet draait, de andere is een proces dat draait en filtert.

Scheid ze met twee controles voordat je iets verandert, want een firewallbewerking op een dode daemon voegt alleen een tweede variabele toe.

Lees de configuratie die DD-WRT genereerde

DD-WRT geeft OpenVPN niet de tekst die je in de webinterface typte. Het schrijft een gegenereerde configuratie naar /tmp/openvpn/openvpn.conf en start de daemon met dat bestand, dus de velden van de interface en alle tekst in Additional Config worden samengevoegd voordat OpenVPN ze ooit ziet. Als je het formulier debugt in plaats van het gegenereerde bestand, lees je een bedoeling en niet de werkelijke invoer. Kopieer dat bestand naar een blijvende plek voordat een herstart /tmp leegmaakt.

Vergelijk het gegenereerde bestand met wat je bedoelde, vooral waar de interface een richtlijn schrijft die je nooit hebt gekozen. Een vervolgkeuzelijst die een verouderde optie uitzendt is onzichtbaar in het formulier en fataal voor de daemon.

Als het gegenereerde bestand leeg is of ontbreekt, is de daemon niet eens aan starten toegekomen, en het probleem ligt stroomopwaarts van OpenVPN.

Wat OpenVPN 2.5 niet meer accepteert

OpenVPN 2.5 verving ncp-ciphers door data-ciphers, en verhoogde de standaard minimale TLS-versie naar 1.2. Het veranderde ook de omgang met compressie, zodat een peer die compressie aanbiedt wordt geweigerd tenzij de configuratie het uitdrukkelijk toestaat, en het markeerde oudere optienamen zoals ns-cert-type als verouderd ten gunste van remote-cert-tls. Elk van die wijzigingen maakt van een eerder werkende configuratie een parse- of onderhandelingsfout.

De faalmodus hangt af van de richtlijn. Een onbekende of verwijderde optie stopt de daemon bij het starten, dat is je dode listener. Een onderhandelingsverschil laat de daemon draaien en weigert clients, wat vanaf de clientkant op een firewallprobleem lijkt.

Lees de eerste fout in de log, niet de laatste. Het parsen stopt bij de eerste slechte richtlijn, en alles daarna is ruis van het afsluiten.

De Broadcom-specifieke voorwaarden

Op Broadcom-builds moet het tunnelapparaat bestaan voordat de daemon het kan gebruiken. Controleer of de tun-module is geladen en of /dev/net/tun aanwezig is, want een ontbrekend apparaat veroorzaakt een startfout die niets met certificaten te maken heeft. Hetzelfde geldt voor de hulpscripts die DD-WRT voor routes en DNS genereert: als ze ontbreken of niet uitvoerbaar zijn, kan de daemon starten en toch zijn installatie niet afmaken.

Start de daemon op de voorgrond met meer detail tegen de gegenereerde configuratie wanneer je de echte melding nodig hebt. Een voorgrondrun print de parsefout die het init-script heeft ingeslikt.

Herstel daarna de normale dienst, want een voorgronddaemon en het init-script vechten om de poort.

Bewijs dat de listener bestaat voordat je clients debugt

Bevestig het proces en de socket apart: één commando voor de draaiende daemon, een ander voor een gebonden UDP-poort op het verwachte adres. Een proces zonder socket betekent dat het nog in de installatie zit of aan de verkeerde interface is gebonden. Het paar is een nuttige test juist omdat de ene helft niet waar kan zijn zonder de andere.

Debuggen aan de clientkant heeft pas zin als de listener bestaat. Controleer dan of de cipher- en TLS-instellingen van de client overeenkomen met de data-ciphers lijst van de server en de minimale versie, en of de poort echt naar de router wordt doorgestuurd.

Bewaar de gegenereerde configuratie en de logregel die de oplossing bewees. De volgende firmware-update kan de standaardwaarden opnieuw wijzigen, en die registratie is wat een herhaling in een controle van vijf minuten verandert.