DD-WRT OpenVPN 2.5-ôfharker dea? Lês de konfiguraasje dy’t it makke hat

In deade ôfharker op DD-WRT betsjut meast dat de daemon stoppe by it parsen fan syn konfiguraasje, net dat in firewallregel de poarte blokkearre hat. OpenVPN 2.5 hat ferskate standertwearden fêstere makke dêr’t âldere konfiguraasjes op fertrouden, en in makke konfiguraasje dy’t op in âldere build wurke, kin wegere wurde foardat de socket ea iepene wurdt. De reden stiet yn it log fan de router sels, en de ynfier stiet yn it makke bestân. Beide yn dy folchoarder lêze is flugger as hokker pakketfangst ek.

De daemon is net de firewall

It ûnderskied is wichtich om’t de beide flaters fan bûten itselde lykje: in klant stjoert in handshake en krijt neat werom. Ien is in proses dat net rint, en de oare is in proses dat rint en filteret.

Skied se mei twa kontrôles foardatst wat feroarest, want in firewall-oanpassing op in deade daemon foeget allinnich in twadde fariabele ta.

Lês de konfiguraasje dy’t DD-WRT makke hat

DD-WRT jout OpenVPN net de tekst dy’tst yn ’e webynterfaasje typt hast. It skriuwt in makke konfiguraasje nei /tmp/openvpn/openvpn.conf en start de daemon mei dat bestân, sadat de fjilden fan ’e ynterfaasje en alle tekst yn Additional Config gearfoege wurde foardat OpenVPN se ea sjocht. As’t it formulier debugst ynstee fan it makke bestân, lêst in bedoeling ynstee fan ’e echte ynfier. Kopiearje dat bestân nei in permaninte plak foardat in werstart /tmp leechmet.

Fergelykje it makke bestân mei watst bedoelde, benammen dêr’t de ynterfaasje in direktive skriuwt dy’tst nea keazen hast. In útklapmenu dat in ferâldere opsje útstjoert is ûnsichtber yn it formulier en deadlik foar de daemon.

As it makke bestân leech is of mist, kaam de daemon sels net ta it starten, en it probleem leit boppe OpenVPN.

Wat OpenVPN 2.5 net mear akseptearret

OpenVPN 2.5 ferfong ncp-ciphers troch data-ciphers, en it ferhege de standert minimale TLS-ferzje nei 1.2. It feroare ek de omgong mei kompresje, sadat in peer dy’t kompresje oanbiedt wegere wurdt útsein as de konfiguraasje it eksplisyt tasteat, en it markearre âldere opsjenammen as ns-cert-type ferâldere ten geunste fan remote-cert-tls. Elk fan dy feroarings makket in earder wurkjende konfiguraasje ta in parse- of ûnderhannelingsflater.

De flatermodus hinget fan ’e direktive ôf. In ûnbekende of fuorthelle opsje stopet de daemon by it starten, dat is dyn deade ôfharker. In ûnderskied by de ûnderhanneling lit de daemon rinne en wegeret klanten, wat fan ’e klantkant as in firewallprobleem liket.

Lês de earste flater yn it log, net de lêste. It parsen stopet by de earste ferkearde direktive, en alles dêrnei is lûd fan it ôfsluten.

De Broadcom-spesifike betingsten

Op Broadcom-builds moat it tunnelapparaat bestean foardat de daemon it brûke kin. Kontrolearje dat de tun-module laden is en dat /dev/net/tun oanwêzich is, want in ûntbrekkend apparaat jout in startflater dy’t neat mei sertifikaten te meitsjen hat. Itselde jildt foar de helperscripts dy’t DD-WRT foar rûtes en DNS makket: as se misse of net útfierber binne, kin de daemon starte en dochs syn ynstelling net ôfmeitsje.

Rin de daemon yn ’e foargrûn mei hegere ferbositeit tsjin ’e makke konfiguraasje as’t de echte melding nedich hast. In foargrûnrin prints de parseflater dy’t it init-skript trochslokte.

Set dêrnei de normale tsjinst werom, want in foargrûndaemon en it init-skript sille om ’e poarte fjochtsje.

Bewiis dat de ôfharker bestiet foardatst klanten debugst

Befêstigje it proses en de socket apart: ien opdracht foar de rinnende daemon, in oare foar in bûne UDP-poarte op it ferwachte adres. In proses sûnder socket betsjut dat it noch yn ynstelling is of oan ’e ferkearde ynterfaasje bûn. It pear is in nuttige test krekt om’t de iene helte net wier wêze kin sûnder de oare.

Debuggen oan ’e klantkant hat pas sin as de ôfharker bestiet. Kontrolearje dan dat de cipher- en TLS-ynstellingen fan ’e klant oerienkomme mei de data-ciphers list fan ’e tsjinner en syn minimale ferzje, en dat de poarte echt nei de router trochstjoerd wurdt.

Bewarje de makke konfiguraasje en de logrigel dy’t de repaasje bewiisde. De folgjende firmware-update kin de standertwearden wer feroarje, en dy registraasje is wat in werhelling yn in fiifminutenkontrôle feroaret.