DD-WRT OpenVPN 2.5-lytteren er død? Les konfigurasjonen den genererte
OpenVPN 2.5 avviser konfigurasjoner som eldre bygg godtok. På DD-WRT bør du lese den genererte filen og daemon-loggen før du rører brannmuren.
En død lytter på DD-WRT betyr vanligvis at daemonen avsluttet mens den parslet konfigurasjonen sin, ikke at en brannmurregel blokkerte porten. OpenVPN 2.5 strammet inn flere standardverdier som eldre konfigurasjoner var avhengige av, og en generert konfigurasjon som fungerte på et eldre bygg kan bli avvist før socketen i det hele tatt åpnes. Årsaken står i ruteren sin egen logg, og inndataene står i den genererte filen. Å lese begge i den rekkefølgen er raskere enn enhver pakkefangst.
Daemonen er ikke brannmuren
Forskjellen betyr noe fordi begge feilene ser like ut utenfra: en klient sender et håndtrykk og får ingenting tilbake. Den ene er en prosess som ikke kjører, den andre er en prosess som kjører og filtrerer.
Skill dem med to kontroller før du endrer noe, for en brannmurredigering på en død daemon legger bare til en andre variabel.
Les konfigurasjonen DD-WRT genererte
DD-WRT gir ikke OpenVPN teksten du skrev inn i webgrensesnittet. Det skriver en generert konfigurasjon til /tmp/openvpn/openvpn.conf og starter daemonen med den filen, så grensesnittfeltene og all tekst i Additional Config slås sammen før OpenVPN i det hele tatt ser dem. Hvis du feilsøker skjemaet i stedet for den genererte filen, leser du en intensjon og ikke den faktiske inndataen. Kopier filen til et varig sted før en omstart /tmp tømmer den.
Sammenlign den genererte filen med det du hadde tenkt, særlig der grensesnittet skriver en direktiv du aldri valgte. En rullegardin som sender ut et utdatert alternativ er usynlig i skjemaet og dødelig for daemonen.
Hvis den genererte filen er tom eller mangler, kom daemonen ikke engang til start, og problemet ligger før OpenVPN.
Hva OpenVPN 2.5 sluttet å godta
OpenVPN 2.5 erstattet ncp-ciphers med data-ciphers, og hevet den minste TLS-versjonen som standard til 1.2. Det endret også håndteringen av komprimering, slik at en motpart som tilbyr komprimering avvises med mindre konfigurasjonen uttrykkelig tillater det, og det gjorde eldre alternativnavn som ns-cert-type utdaterte til fordel for remote-cert-tls. Hver av disse endringene gjør en tidligere fungerende konfigurasjon om til en parse- eller forhandlingsfeil.
Feilmodusen avhenger av direktivet. Et ukjent eller fjernet alternativ stopper daemonen ved oppstart, det er din døde lytter. Et avvik i forhandlingen lar daemonen kjøre og avviser klienter, noe som fra klientsiden ser ut som et brannmurproblem.
Les den første feilen i loggen, ikke den siste. Parsingen stopper ved det første dårlige direktivet, og alt etter det er støy fra nedstengningen.
Forutsetningene som er spesifikke for Broadcom
På Broadcom-bygg må tunnelenheten finnes før daemonen kan bruke den. Kontroller at tun-modulen er lastet og at /dev/net/tun er til stede, fordi en manglende enhet gir en oppstartsfeil som ikke har noe med sertifikater å gjøre. Det samme gjelder hjelpeskriptene DD-WRT genererer for ruter og DNS: hvis de mangler eller ikke er kjørbare, kan daemonen starte og likevel ikke fullføre oppsettet.
Kjør daemonen i forgrunnen med høyere detaljnivå mot den genererte konfigurasjonen når du trenger den virkelige meldingen. En forgrunnskjøring skriver ut parsefeilen som init-skriptet svelget.
Gjenopprett deretter den normale tjenesten, for en forgrunnsdaemon og init-skriptet vil slåss om porten.
Bevis at lytteren finnes før du feilsøker klienter
Bekreft prosessen og socketen hver for seg: én kommando for den kjørende daemonen, en annen for en bundet UDP-port på den forventede adressen. En prosess uten socket betyr at den fortsatt er under oppsett eller bundet til feil grensesnitt. Paret er en nyttig test nettopp fordi den ene halvdelen ikke kan være sann uten den andre.
Feilsøking på klientsiden gir bare mening etter at lytteren finnes. Sjekk da at klientens chiffer og TLS-innstillinger samsvarer med serverens data-ciphers liste og minsteversjon, og at porten faktisk videresendes til ruteren.
Ta vare på den genererte konfigurasjonen og logglinjen som beviste rettelsen. Den neste fastvareoppdateringen kan endre standardverdiene igjen, og den registreringen er det som gjør en gjentakelse til en femminutters sjekk.