DD-WRT OpenVPN 2.5-lytteren er død? Læs den konfiguration, den genererede

En død lytter på DD-WRT betyder normalt, at daemonen afsluttede, mens den parsede sin konfiguration, ikke at en firewallregel blokerede porten. OpenVPN 2.5 har strammet flere standardværdier, som ældre konfigurationer lænede sig op ad, og en genereret konfiguration, der virkede på et ældre build, kan blive afvist, før soklen overhovedet åbnes. Årsagen står i routerens egen log, og inputtet står i den genererede fil. At læse begge i den rækkefølge er hurtigere end enhver pakkefangst.

Daemonen er ikke firewallen

Forskellen er vigtig, fordi de to fejl ser ens ud udefra: en klient sender et håndtryk og får intet igen. Den ene er en proces, der ikke kører, og den anden er en proces, der kører og filtrerer.

Adskil dem med to kontroller, før du ændrer noget, for en firewallrettelse på en død daemon tilføjer bare en anden variabel.

Læs den konfiguration, DD-WRT genererede

DD-WRT giver ikke OpenVPN den tekst, du skrev i webgrænsefladen. Den skriver en genereret konfiguration til /tmp/openvpn/openvpn.conf og starter daemonen med den fil, så grænsefladens felter og enhver tekst i Additional Config flettes, før OpenVPN overhovedet ser dem. Hvis du fejlretter formularen i stedet for den genererede fil, læser du en hensigt i stedet for det faktiske input. Kopiér filen til et varigt sted, før en genstart /tmp rydder.

Sammenlign den genererede fil med det, du havde tænkt dig, især hvor grænsefladen skriver en direktiv, du aldrig har valgt. En rullemenu, der udsender en forældet mulighed, er usynlig i formularen og dødelig for daemonen.

Hvis den genererede fil er tom eller mangler, nåede daemonen slet ikke at starte, og problemet ligger før OpenVPN.

Hvad OpenVPN 2.5 holdt op med at acceptere

OpenVPN 2.5 erstattede ncp-ciphers med data-ciphers, og den hævede den mindste TLS-version som standard til 1.2. Den ændrede også håndteringen af komprimering, så en peer, der tilbyder komprimering, afvises, medmindre konfigurationen udtrykkeligt tillader det, og den gjorde ældre mulighedsnavne som ns-cert-type forældede til fordel for remote-cert-tls. Hver af disse ændringer gør en tidligere fungerende konfiguration til en parse- eller forhandlingsfejl.

Fejltypen afhænger af direktivet. En ukendt eller fjernet mulighed stopper daemonen ved opstart, og det er din døde lytter. En uenighed i forhandlingen lader daemonen køre og afviser klienter, hvilket fra klientsiden ligner et firewallproblem.

Læs den første fejl i loggen, ikke den sidste. Parsingen stopper ved det første dårlige direktiv, og alt derefter er støj fra nedlukningen.

Forudsætningerne, der er specifikke for Broadcom

På Broadcom-builds skal tunnel-enheden findes, før daemonen kan bruge den. Kontrollér, at tun-modulet er indlæst, og at /dev/net/tun er til stede, fordi en manglende enhed giver en opstartsfejl, der intet har med certifikater at gøre. Det samme gælder de hjælpescripts, DD-WRT genererer til ruter og DNS: hvis de mangler eller ikke er eksekverbare, kan daemonen starte og alligevel ikke fuldføre sin opsætning.

Kør daemonen i forgrunden med højere detaljeringsgrad mod den genererede konfiguration, når du har brug for den rigtige besked. En forgrundskørsel udskriver den parsefejl, som init-scriptet slugte.

Gendan derefter den normale tjeneste, for en forgrundsdaemon og init-scriptet vil slås om porten.

Bevis, at lytteren findes, før du fejlretter klienter

Bekræft processen og soklen hver for sig: én kommando til den kørende daemon, en anden til en bundet UDP-port på den forventede adresse. En proces uden sokkel betyder, at den stadig er under opsætning eller bundet til den forkerte grænseflade. Parret er en nyttig test, netop fordi den ene halvdel ikke kan være sand uden den anden.

Fejlretning på klientsiden giver først mening, når lytteren findes. Så kontrollér, at klientens cipher- og TLS-indstillinger matcher serverens data-ciphers liste og minimumsversion, og at porten faktisk videresendes til routeren.

Gem den genererede konfiguration og den loglinje, der beviste rettelsen. Den næste firmwareopdatering kan ændre standardværdierne igen, og den registrering er det, der gør en gentagelse til et femminutters tjek.