Nino-encrypt ba ng VPN mo ang DNS, o ang susunod na hop lang?

Ang pag-enable ng naka-encrypt na DNS sa VPN server ay madalas ilarawan bilang pagsasara ng isang pagtagas, at itinatago ng paglalarawang iyon kung aling koneksyon ang nagbago. Ang hop mula sa kliyente patungo sa resolver at ang hop mula sa resolver patungo sa upstream ay magkahiwalay na koneksyon na may magkahiwalay na may-ari. Ang pag-encrypt sa isa ay iniiwan ang isa nang eksaktong dati.

Isulat kung sino ang tumatanggap ng query sa bawat yugto bago mo hawakan ang isang configuration file.

Dalawang setup ang magkamukha sa pahina ng mga setting

Sa unang setup, ang device mismo ang nagpapatakbo ng DNS over TLS, at ang tunnel ay nagdadala lang ng koneksyong iyon sa isang resolver na pinili mo. Nagtatapos ang TLS session sa resolver, ibig sabihin nakikita ng resolver ang query at ang labasan ng VPN ay nakikita ang naka-encrypt na teksto na hindi nito mabasa. Sa ikalawang setup, ipinapadala ng device ang ordinaryong DNS sa pamamagitan ng tunnel patungo sa isang forwarder sa VPN host, at binubuksan ng forwarder na iyon ang sarili nitong naka-encrypt na koneksyon sa isang upstream resolver. Sa isang listahan ng feature, parehong mukhang "naka-encrypt na DNS na may VPN", at inilalagay nila ang nababasang query sa magkaibang gusali.

Ang pagkakaiba ay nasusukat, hindi pilosopikal. Hanapin ang TLS session sa kliyente o sa server, at malalaman mo kung aling setup talaga ang mayroon ka.

I-mapa ang kadena ng resolver bago mo ito baguhin

Bilangin ang mga resolver sa landas at pangalanan ang papel ng bawat isa. Ang isang forwarding component ay nagbibigay ng kahilingan sa ibang resolver, habang ang isang recursive resolver ay gumagawa ng trabaho ng paghahanap ng sagot at maaaring makipag-usap nang direkta sa mga authoritative server. Ang mga papel na ito ay hiwalay na tinukoy dahil mismo sa kadahilanang ito, at ang mga depinisyon ng resolver sa RFC 9076 ay sulit basahin bago mo ipagpalagay na may isang upstream destinasyon lamang. Ang isang host na nagpapatakbo ng sariling recursive resolver ay walang isang "upstream" na maaaring i-encrypt, na nagpapawalang-bisa sa buong plano.

Pagkatapos, itanong kung aling component ang naka-configure na gamitin ng kliyente. Ang DNS address na ibinibigay ng VPN profile ay nagsasabi kung saan pumupunta ang mga query, hindi kung aling proseso ang sumasagot sa kanila.

Pansinin din ang pag-uugali kapag nabigo. Kung ang naka-encrypt na upstream ay hindi maabot, nabibigo ba ang forwarder nang sarado, bumabalik ba ito sa plaintext, o lumilipat sa ibang resolver? Ang desisyong iyon ay dapat nasa talaan, dahil binabago nito ang garantiyang pangpribasya sa sandaling pinakamahina ang tunnel.

I-verify kung aling hop ang naka-encrypt

Magsimula sa kliyente at kumpirmahin kung mayroon itong TLS session sa port 853. Ang isang query na tama ang resolusyon sa port 53 ay walang pinapatunayan tungkol sa encryption.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Pagkatapos, pumunta sa VPN host at hanapin ang palabas na naka-encrypt na koneksyon na binuksan ng forwarder. Sinasabi ng socket table kung may upstream TLS session at kung aling proseso ang may-ari nito:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Kung ang kliyente ay nagpapakita ng TLS session at ang server ay wala, nasa unang setup ka at hindi mabasa ng server ang mga query na ipinapasa nito sa IP layer. Kung ang server ang nagpapakita ng TLS session at ang kliyente ay ordinaryong trapiko sa port 53 sa loob ng tunnel, nasa ikalawang setup ka: protektado ang susunod na hop, at binabasa pa rin ng forwarder ang bawat pangalan na hinihiling ng device. Ang ikalawang resultang iyon ay hindi pagkabigo, ngunit ang tawagin itong end-to-end encryption ay mali.

Itala ang may-ari at ang pag-uugali kapag nabigo

Ang pagmamay-ari ang nagpapasya kung ano ang puwede mong ipangako. Kinokontrol ng may-ari ng device ang naka-encrypt na koneksyon sa panig ng kliyente, habang kinokontrol ng VPN administrator ang susunod na koneksyon na ginagawa ng forwarder nito. Sinumang hindi nagpapatakbo ng alinman sa dalawa ay makapaglalarawan lamang ng landas.

Bago mag-enable ng kahit ano, suriin ang panloob na pagpapangalan. Ang pagpapadala ng mga pangalan ng organisasyon sa isang pampublikong resolver ay hindi katumbas na disenyo, at ang isang split-horizon zone na umiiral lamang sa loob ng network ay hindi maresolba sa upstream. Subukan ang isang panloob at isang pampublikong pangalan pagkatapos ng pagbabago, at itago ang resulta kasama ng pagbabago sa configuration. Kung sinira ng naka-encrypt na landas ang resolusyon para sa mga panloob na host, ang pagwawasto ay isang scoped resolver rule, hindi isang mas malawak na tunnel.

Tapusin sa pamamagitan ng pagsulat ng isang pangungusap bawat hop: aling component ang tumanggap ng query, kung naka-encrypt ang hop na iyon, at sino ang makakabasa ng pangalan. Kapag ang pangungusap tungkol sa VPN host ay nagsasabi pa ring nababasa nito ang mga query, dapat sabihin iyon ng dokumentasyon, dahil ang diagram na nagsasabi ng kabaligtaran ay pagtitiwalaan ng taong hindi kailanman nagpatakbo ng mga utos.