Patay na ba ang listener ng OpenVPN 2.5 sa DD-WRT? Basahin ang konfigurasyong ginawa nito

Ang patay na listener sa DD-WRT ay karaniwang nangangahulugang umalis ang daemon habang sinusuri ang konfigurasyon nito, hindi na hinarang ng tuntunin ng firewall ang port. OpenVPN 2.5 ay naghigpit ng ilang default na inaasahan ng lumang konfigurasyon, at ang ginawang konfigurasyong gumana sa lumang build ay maaaring tanggihan bago pa man mabuksan ang socket. Nasa log ng router mismo ang dahilan, at nasa ginawang file ang input. Ang pagbasa sa dalawa sa ganitong pagkakasunod ay mas mabilis kaysa sa anumang paghuli ng packet.

Ang daemon ay hindi ang firewall

Mahalaga ang pagkakaiba dahil magkapareho ang itsura ng dalawang pagkabigo mula sa labas: nagpapadala ng handshake ang kliyente at walang bumabalik. Ang isa ay prosesong hindi tumatakbo, ang isa ay prosesong tumatakbo at nagsasala.

Paghiwalayin sila sa dalawang pagsusuri bago magbago ng anuman, dahil ang pag-edit ng firewall sa patay na daemon ay nagdadagdag lamang ng ikalawang baryabol.

Basahin ang konfigurasyong ginawa ng DD-WRT

Hindi ibinibigay ng DD-WRT sa OpenVPN ang tekstong itinaip mo sa web interface. Nagsusulat ito ng ginawang konfigurasyon sa /tmp/openvpn/openvpn.conf at sinisimulan ang daemon gamit ang file na iyon, kaya pinagsasama ang mga field ng interface at anumang teksto sa Additional Config bago pa ito makita ng OpenVPN. Kung ini-debug mo ang form sa halip na ang ginawang file, binabasa mo ang intensyon at hindi ang tunay na input. Kopyahin ang file na iyon sa permanenteng lugar bago burahin ng restart ang /tmp.

Ihambing ang ginawang file sa layunin mo, lalo na kung saan nagsusulat ang interface ng direktiba na hindi mo kailanman pinili. Ang dropdown na naglalabas ng lipas na opsyon ay hindi nakikita sa form at nakamamatay sa daemon.

Kung walang laman o wala ang ginawang file, hindi man lang umabot sa pagsisimula ang daemon, at ang problema ay nasa itaas ng OpenVPN.

Ano ang tinigilan ng OpenVPN 2.5 na tanggapin

Pinalitan ng OpenVPN 2.5 ang ncp-ciphers ng data-ciphers, at itinaas ang default na pinakamababang bersyon ng TLS sa 1.2. Binago rin nito ang paghawak sa compression, kaya ang kapares na nag-aalok ng compression ay tinatanggihan maliban kung hayagang pinapayagan ng konfigurasyon, at minarkahan nitong lipas ang mas lumang pangalan ng opsyon tulad ng ns-cert-type kapalit ng remote-cert-tls. Bawat isa sa mga pagbabagong iyon ay ginagawang pagkabigo sa pagsusuri o pakikipagkasundo ang dating gumaganang konfigurasyon.

Nakadepende sa direktiba ang paraan ng pagkabigo. Ang hindi kilalang o tinanggal na opsyon ay humihinto sa daemon sa pagsisimula, iyon ang patay mong listener. Ang hindi pagkakatugma sa pakikipagkasundo ay hinahayaang tumakbo ang daemon at tinatanggihan ang mga kliyente, na mukhang problema sa firewall mula sa panig ng kliyente.

Basahin ang unang error sa log, hindi ang huli. Humihinto ang pagsusuri sa unang masamang direktiba, at ang lahat pagkatapos nito ay ingay mula sa pagsasara.

Ang mga paunang kailangan na partikular sa Broadcom

Sa mga build ng Broadcom dapat umiiral ang tunnel device bago ito magamit ng daemon. Tiyakin na nakaload ang tun module at may /dev/net/tun , dahil ang nawawalang device ay nagdudulot ng pagkabigo sa pagsisimula na walang kinalaman sa mga sertipiko. Ganoon din sa mga helper script na ginagawa ng DD-WRT para sa ruta at DNS: kung wala o hindi maipapatupad, maaaring magsimula ang daemon at hindi pa rin matapos ang setup nito.

Patakbuhin ang daemon sa foreground na may mas detalyadong output laban sa ginawang konfigurasyon kapag kailangan mo ang tunay na mensahe. Ang foreground run ay naglilimbag ng error sa pagsusuri na nilamon ng init script.

Pagkatapos ay ibalik ang normal na serbisyo, dahil mag-aagawan sa port ang foreground daemon at ang init script.

Patunayan na may listener bago i-debug ang mga kliyente

Kumpirmahin ang proseso at ang socket nang hiwalay: isang utos para sa tumatakbong daemon, isa pa para sa nakatali na UDP port sa inaasahang address. Ang prosesong walang socket ay nangangahulugang nasa setup pa ito o nakatali sa maling interface. Kapaki-pakinabang ang pares na ito dahil hindi maaaring totoo ang isang kalahati nang wala ang isa.

Makatuwiran lamang ang debugging sa panig ng kliyente kapag may listener na. Pagkatapos ay tiyakin na tumutugma ang cipher at TLS settings ng kliyente sa listahan ng data-ciphers ng server at sa pinakamababang bersyon nito, at tunay na naipapasa ang port sa router.

Itago ang ginawang konfigurasyon at ang log line na nagpatunay ng pagwawasto. Maaaring baguhin muli ng susunod na firmware update ang mga default, at ang rekord na iyon ang nagiging dahilan upang ang pag-ulit ay maging limang minutong pagsusuri.