Listenerul OpenVPN 2.5 din DD-WRT a murit? Citiți configurația generată

Un listener mort pe DD-WRT înseamnă de obicei că daemonul a ieșit în timp ce își analiza configurația, nu că o regulă de firewall a blocat portul. OpenVPN 2.5 a înăsprit mai multe valori implicite pe care se bazau configurațiile mai vechi, iar o configurație generată care funcționa pe o versiune mai veche poate fi respinsă înainte ca socketul să se deschidă. Motivul este în jurnalul routerului însuși, iar intrarea în fișierul generat. Citirea ambelor în această ordine este mai rapidă decât orice captură de pachete.

Daemonul nu este firewall-ul

Distincția contează pentru că cele două defecțiuni arată identic din exterior: un client trimite un handshake și nu primește nimic înapoi. Una este un proces care nu rulează, cealaltă este un proces care rulează și filtrează.

Separați-le cu două verificări înainte de a schimba ceva, pentru că o editare a firewall-ului pe un daemon mort adaugă doar o a doua variabilă.

Citiți configurația generată de DD-WRT

DD-WRT nu îi dă lui OpenVPN textul tastat în interfața web. Scrie o configurație generată în /tmp/openvpn/openvpn.conf și pornește daemonul cu acel fișier, așa că câmpurile interfeței și orice text din Additional Config sunt contopite înainte ca OpenVPN să le vadă. Dacă depanați formularul în locul fișierului generat, citiți o intenție și nu intrarea reală. Copiați acel fișier într-un loc permanent înainte ca o repornire /tmp să îl golească.

Comparați fișierul generat cu ceea ce intenționați, mai ales acolo unde interfața scrie o directivă pe care nu ați ales-o niciodată. Un meniu derulant care emite o opțiune învechită este invizibil în formular și fatal pentru daemon.

Dacă fișierul generat este gol sau lipsește, daemonul nici nu a ajuns la pornire, iar problema este deasupra OpenVPN.

Ce a încetat OpenVPN 2.5 să accepte

OpenVPN 2.5 a înlocuit ncp-ciphers cu data-ciphers, și a ridicat versiunea minimă TLS implicită la 1.2. A schimbat și modul de tratare a compresiei, astfel încât un partener care oferă compresie este refuzat dacă configurația nu permite explicit, și a marcat ca învechite numele de opțiuni mai vechi precum ns-cert-type în favoarea remote-cert-tls. Fiecare dintre aceste schimbări transformă o configurație care funcționa într-un eșec de analiză sau de negociere.

Modul de eșec depinde de directivă. O opțiune necunoscută sau eliminată oprește daemonul la pornire, acesta este listenerul mort. O nepotrivire de negociere lasă daemonul să ruleze și refuză clienții, ceea ce din partea clientului arată ca o problemă de firewall.

Citiți prima eroare din jurnal, nu pe ultima. Analiza se oprește la prima directivă greșită, iar tot ce urmează este zgomot de la oprire.

Cerințele specifice Broadcom

Pe versiunile Broadcom dispozitivul de tunel trebuie să existe înainte ca daemonul să îl poată folosi. Verificați că modulul tun este încărcat și că /dev/net/tun este prezent, pentru că un dispozitiv lipsă produce un eșec de pornire care nu are nimic de-a face cu certificatele. Același lucru este valabil pentru scripturile auxiliare pe care DD-WRT le generează pentru rute și DNS: dacă lipsesc sau nu sunt executabile, daemonul poate porni și totuși nu își termină configurarea.

Rulați daemonul în prim-plan cu mai mult detaliu asupra configurației generate când aveți nevoie de mesajul real. O rulare în prim-plan tipărește eroarea de analiză pe care scriptul init a înghițit-o.

Apoi restabiliți serviciul normal, pentru că un daemon în prim-plan și scriptul init se vor certa pe port.

Dovediți că listenerul există înainte de a depana clienții

Confirmați procesul și socketul separat: o comandă pentru daemonul care rulează, alta pentru un port UDP legat la adresa așteptată. Un proces fără socket înseamnă că este încă în configurare sau legat la interfața greșită. Perechea este un test util exact pentru că o jumătate nu poate fi adevărată fără cealaltă.

Depanarea pe partea clientului are sens doar după ce listenerul există. Atunci verificați că cifrul și setările TLS ale clientului corespund listei data-ciphers a serverului și versiunii sale minime, și că portul este într-adevăr redirecționat către router.

Păstrați configurația generată și linia din jurnal care a dovedit remedierea. Următoarea actualizare de firmware poate schimba din nou valorile implicite, iar acea înregistrare este cea care transformă o repetare într-o verificare de cinci minute.