OpenVPN sa port 53: tatlong usapan na nakakalito
Ang paghahanap ng endpoint, ang naka-encrypt na transport at ang DNS pagkatapos ng tunnel ay tatlong usapan. Tukuyin kung aling yugto ang nabigo bago magpalit ng port o resolver.
Ang mga ulat na nagsasabing naka-block ang VPN sa port 53 ay pinagsasama ang tatlong obserbasyon na nabibigo sa magkaibang dahilan. Ang paghahanap ng pangalan ng endpoint ay nangyayari bago pa man may tunnel, ang naka-encrypt na transport ay hiwalay na usapan, at ang mga DNS query na ginagawa pagkatapos ay ang pangatlo. Bawat isa ay may sariling tanda ng pagpalya, at isa lamang sa kanila ang tungkol sa DNS.
Bago magbago ng kahit ano, paghiwalayin ang mga packet ayon sa layunin, dahil sinusundan ng pag-aayos ang yugto.
Tatlong usapan, isang numero ng port
Ang unang usapan ay paghahanap ng pangalan para sa endpoint: tinatanong ng iyong makina ang naka-configure na resolver kung saan naroon ang vpn.example.com, at ang sagot na iyon ay dumarating sa ordinaryong DNS bago pa magpadala ang client ng kahit isang tunnel packet. Ang pangalawa ay ang transport ng OpenVPN mismo, na kumokonekta sa address na ibinigay ng paghahanap sa protocol at port na sinasabi ng profile. Ang pangatlo ay nangyayari pagkatapos na umangat ang tunnel, kapag humihingi ng mga pangalan ang mga application at ang ipinadalang resolver settings ang nagpapasya kung sino ang sasagot.
Ang tatlong ito ay maaaring magtagumpay o mabigo nang magkahiwalay. Maaaring perpektong i-resolve ng client ang endpoint nito at hindi pa rin maabot ang listener, at maaari itong magtatag ng tunnel habang nabibigo ang bawat panloob na paghahanap ng pangalan dahil hindi kailanman dumating ang DNS settings.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Basahin ang talahanayan bilang checklist at hindi bilang paglalarawan. Kung hindi ma-resolve ang pangalan ng endpoint, wala nang ibang gagana pagkatapos, at hindi kailanman nagsisimula ang tunnel.
Hindi pinapangalanan ng numero ng port ang application
Nagdadala ang port 53 ng DNS ayon sa kaugalian, at ang isang OpenVPN operator ay maaari ring maglathala ng listener doon, at iyon mismo ang dahilan kung bakit mahinang identifier ang numero. Ang OpenVPN session sa UDP 53 ay OpenVPN session pa rin, at ang DNS query sa isang server sa port 53 ay walang sinasabi tungkol sa kung pinapayagan ang tunnel. Ang mga linyang proto at remote ng profile ang tumutukoy sa panlabas na endpoint; ang numero ng port mismo ay walang tinutukoy.
Kapag nag-diagnose, pumuputok ito sa magkabilang panig: ang pangkalahatang UDP probe sa port 53 ay nagpapatunay na may port na sumasagot, hindi na ang serbisyong VPN ang sumasagot. Subukan gamit ang tunay na client at tunay na profile, dahil iyon lamang ang nagsasanay ng handshake na inaasahan ng serbisyo.
Patunayan ang listener bago sisihin ang network
Sa server, tiyakin kung ano ang nakatali gamit ang ss -lunp | grep 53 at ihambing sa protocol at port ng profile. Mula sa network ng client, patakbuhin ang client nang may mas detalyadong log upang makita kung aling address at transport ang sinubukan nito. Kung nakikinig ang server at hindi dumarating ang mga packet ng client, tinatanggihan ang mga ito ng ruta o patakaran, at iyon ay usapan sa may-ari ng network at hindi dahilan para magpalit ng port.
Ang ibang port ay nakakatulong lamang kapag talagang nakikinig doon ang serbisyo at pinapayagan ito ng deployment. Ang paglipat ng listener para maiwasan ang pag-filter ng isang pinamamahalaang network ay desisyon sa patakaran, hindi hakbang sa pag-troubleshoot. Itanong sa may-ari ng network kung ano ang pinapayagan bago baguhin ang serbisyo, dahil ang paraan ng pag-iwas na lumalabag sa patakaran ay isinasara rin sa bandang huli. Isulat ang sagot na iyon sa tabi ng profile upang hindi ulitin ng susunod na tao ang kahilingan.
Suriin ang DNS pagkatapos ng tunnel, nang hiwalay
Kapag umangat na ang tunnel, suriin ang estado ng resolver sa interface ng VPN at magtanong ng isang panloob at isang pampublikong pangalan. Kung nabibigo ang mga panloob na pangalan habang nagdadala ng trapiko ang tunnel, hindi naipatupad ang ipinadalang DNS settings, na isyu ng integrasyon ng client at hindi ng transport. Kung nabibigo ang mga pampublikong pangalan at gumagana ang mga panloob, ginagawa ng patakaran ng split tunnel ang layunin nito.
Iwanan ang mga pagbabago sa DNS sa may-ari ng resolver. Ang pagsulat sa ibabaw ng pinamamahalaang resolver configuration para pumasa ang isang test ay maaaring makasira ng pribadong pangalan para sa lahat ng iba pa sa makina. Kung nagpapadala ang tunnel ng resolver at binabalewala ito ng client, ayusin ang integrasyon ng client sa halip na magdagdag ng static na entry sa ibang lugar. Itinatago ng mga static na entry ang pagpalya hanggang may magpalit ng network. Isulat kung aling resolver ang inaasahang sasagot sa bawat namespace.