Netgear OpenVPN: TUN at TAP nakikinig sa magkaibang port

Kumokonekta ang telepono sa VPN ng router nang walang reklamo, habang ang laptop na gumagamit ng profile mula sa parehong pahina ng download ay nag-timeout. Walang nagbago sa mga sertipiko sa pagitan ng dalawang pagtatangkang iyon, dahil hindi kailanman nakarating ang laptop sa puntong mahalaga ang mga sertipiko. Naglilimbag ang router ng hiwalay na mga listener para sa TUN at TAP, at ang gumaganang profile ay kailangang pumili ng kabilang sa sarili nitong uri ng aparato.

Ang pagpapasya kung alin sa tatlong posibleng depekto ang hahabulin ay ang buong gawain dito: ang port, ang uri ng aparato, o ang negosasyon ng cipher ng channel ng datos.

Tatlong bagay na dapat magtugma

Ang uri ng aparato, ang linya ng interface ng profile at ang port ng listener ay bumubuo ng isang pagpipilian, hindi tatlo. Ang profile na nagdedeklara ng dev tun at nakaturo sa listener ng TAP ay hindi makakumpleto ng session, at ang kabaligtaran ay nabibigo nang pareho. Para sa iyong modelo at firmware, basahin ang port mula sa sariling pahina ng VPN ng router at hindi mula sa gabay, dahil nagbabago ang mga numero sa pagitan ng mga build. Isulat ang modelo at bersyon ng firmware sa tabi ng numerong iyon upang ma-verify ito ng susunod na tao.

Binabanggit ng mga ulat mula sa field ang isang pares tulad ng 12973 para sa TUN at 12974 para sa TAP sa isang firmware, at ibang numero sa isa pa. Basahin ang mga ito bilang patunay na magkaiba ang mga build, hindi bilang mga constant na kokopyahin. Kailangan naman ng profile ang hostname na angkop sa distansya: ang dynamic na pangalan ng DNS ng router sa halip na address ng WAN na magbabago.

Matapos itama ang port at ang linya ng interface, mukhang normal na configuration ng client ang profile na may isang linyang remote at isang linyang dev. Kung hindi magtugma ang dalawa, walang dami ng pag-uulit ang gumagawa ng session.

Basahin ang log sa ayos na inilalathala nito

Ang client ng OpenVPN ay nag-uulat ng mga pangyayari sa ayos ng pagganap ng mga ito, kaya tinutukoy ng huling linya bago ang katahimikan ang layer na dapat suriin. Kapag nagtapos ang pagtakbo sa TLS Error: TLS key negotiation failed, o naghihintay lamang ng unang tugon at sumusuko, hindi kailanman nangyari ang paghahambing ng sertipiko. Itinuturo niyon ang maabot, ang listener, o ang port na walang anuman sa likod. Wala sa mga iyon ang naaayos sa pamamagitan ng pagpapalit ng file ng CA.

Ang pagtakbo na umabot sa VERIFY OK at pagkatapos ay nabigo ay nasa ibang lugar nang lubusan, kasama ang sarili nitong mga dahilan. Ang paghihiwalay ng dalawang kinalabasang iyon bago hawakan ang mga file ay pumipigil sa klasikong pagliko sa mga bundle ng sertipiko na hindi kailanman tinanong. Kapag natapos ang handshake ngunit hindi bumabangon ang tunnel, tingnan ang negosasyon ng cipher sa halip na ang maabot.

Idagdag ang listahan ng cipher na inaasahan ng modernong client

Tinatanggihan ng mga kamakailang client ng OpenVPN ang mga lumang default na iniaalok pa rin ng firmware sa bahay, at ang sintomas ay pagkabigo sa negosasyon kaagad pagkatapos ng matagumpay na handshake. Ang pagwawasto ay isang linya ng profile na nagpangalan sa tatanggapin ng client: itakda ang data-ciphers sa AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 at AES-128-CBC sa ayos na iyon. Anumang algorithm na hindi ipinatutupad ng router ay hindi kailanman pinipili, kaya ang mas mahabang listahan ay walang gastos maliban sa bahagyang mas mahabang negosasyon.

Ang paglilista ng mga cipher ay hindi nagtuturo sa router ng wala ito. Kung nabibigo pa rin ang negosasyon, tingnan kung may sariling setting ng cipher ang pahina ng router at kung may kasamang kahit isang entry ang setting na iyon na tinatanggap ng client. Dalawang listahang walang karaniwang miyembro ay gumagawa ng eksaktong parehong pagkabigo gaya ng maling port, kaya karapat-dapat tingnan ang magkabilang dulo.

Mag-import nang isang beses sa halip na i-edit ang mga kopya nang manu-mano

Ang pag-import ng itinamang file sa NetworkManager ay umiiwas sa folder na puno ng bahagyang magkaibang mga profile: nmcli connection import type openvpn file client.ovpn, pagkatapos ay iangat ito sa pamamagitan ng pangalan. Panatilihin ang na-import na profile bilang nag-iisang kopyang ine-edit mo, at tanggalin ang mga duplicate na naipon mula sa paulit-ulit na pag-download.

Pagkatapos ay subukan mula sa labas ng LAN. Ang pagkonekta mula sa parehong network ay nagpapatunay ng napakaliit, dahil maaaring hindi dumaan ang trapiko sa tunnel. Kumpirmahin na talagang lumalabas ang isang kahilingan sa router, hindi lamang na nagpapakita ang client ng konektadong estado.

Magpasya kung ano ang gagawin sa mga babala

Karaniwang gumagawa ang firmware sa bahay ng sarili nitong awtoridad ng sertipiko, at nagrereklamo ang mga client tungkol sa pag-verify sa mga paraang hindi mapipigilan ng firmware. Hatulan kung mahalaga ang reklamong iyon sa ipinoprotektahan mo sa halip na ituring na nakamamatay ang bawat babala, at huwag i-off ang pag-verify nang pandaigdigan para lamang patahimikin ang isang mensahe. Ang babalang sinuri mo ay dokumentadong panganib; ang setting ng pag-verify na inalis mo ay hindi dokumentado.

Kapag walang sinusuportahang paraan ang firmware para itama ang isang babalang talagang mahalaga, ang puwang na iyon ay nagsasabi pabor sa pagho-host ng VPN sa ibang lugar. Ang pagpili sa pagitan ng pagkukumpuni ng profile, pagtanggap ng babala at paglipat ng endpoint ay desisyon tungkol sa gaano mo pinagkakatiwalaan ang sertipikong iyon. Gawin ito nang sinasadya, at isulat kung aling opsyon ang pinili mo, sa halip na mag-click sa mga dialog hanggang maging berde ang icon.