Ang VPN sa DNS ay hindi katulad ng DNS server ng VPN

Ang VPN sa DNS ay naglalarawan ng ideya ng transport, at hindi ito kasingkahulugan ng pagturo ng device sa isang custom na resolver. Ang tanong na nagtatapos sa kalituhan ay simple: ano ba talaga ang dinadala ng mga mensahe ng DNS? Ang ordinaryong VPN ay maaaring mag-install ng resolver upang ang mga sakop na app ay makahanap ng pribadong pangalan, at ang pagbabago ng resolver na iyon ay nagbabago lamang ng resolusyon ng pangalan. Patakbuhin ang mga pagsusuri sa ibaba nang sunod-sunod, dahil ang tatlong kaayusan ay nagbabahagi ng bokabularyo at halos wala nang iba.

Paghiwalayin ang tatlong kaayusan

Sa unang kaayusan, ang VPN ay nagbibigay ng resolver o setting ng patakaran sa pangalan. Ang data ng app ay naglalakbay pa rin sa sarili nitong mga koneksyon sa network, at ang tunnel ay nakakaapekto lamang kung aling server ang sumasagot sa query.

Sa ikalawa, pinoprotektahan ng naka-encrypt na DNS ang palitan ng DNS mismo. Ang DNS sa HTTPS at DNS sa TLS ay bumabalot sa mga query patungo sa piniling resolver, at hindi sila nagdadala ng packet ng ibang app. Hindi rin nila itinatago ang mga pangalan ng query mula sa resolver na pinili mo, na isang ibang hangganan ng pagtitiwala kaysa sa pagtatago ng mga ito mula sa lokal na network.

Sa ikatlo, ang isang kooperatibang client ay nag-encode ng ibang data sa mga mensahe ng DNS at ang isang kooperatibang endpoint ay muling bumubuo nito. Ang ordinaryong landas ng resolver ang nagiging transport, at ang resolver ay bahagi na ngayon ng landas ng data sa halip na isang serbisyo ng pangalan.

Suriin kung ano ang dinadala ng mga mensahe ng DNS

Baguhin ang resolver at obserbahan kung nagbabago ang landas ng trapiko ng app. Kung kumokonekta pa rin ang app sa parehong mga address sa parehong mga socket, binago mo ang resolusyon ng pangalan at wala nang iba.

Ang tunnel na dinadala ng DNS ay nangangailangan ng katumbas na kaayusan sa panig ng server. Ang Iodine ay isang dokumentadong halimbawa: dokumentasyon ng proyekto nito ay naglalarawan ng IP tunnel sa DNS, at nangangailangan ito ng bahagi ng server na nakakaunawa ng encoding. Ang paglalagay ng pampublikong address ng resolver sa Android ay hindi nagbibigay ng endpoint na iyon, at ang terminong pang-market na pinagsasaluhan ng dalawang produkto ay hindi isang spesipikasyon ng protocol.

Ang pagkuha ng packet ang mapagpasyang pagsusuri. Kung puro ordinaryong query sa resolver lang ang nakikita mo at wala nang iba, walang tunnel. Kung may payload na naka-encode sa mga pangalan ng query at mga sagot, natagpuan mo ang carrier, at ang susunod na tanong ay kung gaano karami ang kaya nitong ilipat.

Suriin ang kapasidad bago mag-commit

Ang DNS ay dinisenyo para sa mga query at sagot, hindi para sa maramihang paghahatid. Ang overhead ng encoding, mga limitasyon sa laki ng mensahe at pag-uugali ng resolver ay kumukuha ng kanilang parte sa nominal na landas, kaya ang kapaki-pakinabang na kapasidad ay mas mababa kaysa sa ipinahihiwatig ng pinagbabatayang link. Ituring ang anumang bilang ng throughput na hindi mo sinukat sa sarili mong landas bilang hinuha at hindi badyet. Sukatin ang parehong direksyon, dahil ang pag-upload at pag-download ay maaaring tumama sa magkaibang limitasyon sa isang carrier na uri ng query-sagot.

Kailangan ding magpasya ng client kung aling trapiko ang papasok sa tunnel. Ang lokal na interface ng serbisyo ng VPN ay maaaring mangolekta ng packet, ngunit walang sinasabi ang interface tungkol sa kung paano pinoprotektahan o ipinapasa ng remote na transport ang mga ito. Iba ang pag-uugali ng fragmentation at retransmission kapag ang carrier ay isang protocol ng query at sagot sa halip na isang stream, at ang koneksyong nananatiling bukas ay kaunti lang ang sinasabi tungkol sa interactive na latency.

Sukatin gamit ang trapikong balak mong dalhin. Ang tunnel na mukhang maayos para sa pana-panahong tibok ay maaaring hindi magamit para sa interactive na sesyon, at totoo rin ang kabaligtaran.

Suriin ang seguridad ng carrier

Huwag ipagpalagay na ang encapsulation ng DNS ay nagbibigay ng pagiging kumpidensyal o malakas na authentication. Nakikita ng landas ng resolver at endpoint ng tunnel ang inilalantad ng implementasyon, at nag-iiba ang exposure na iyon ayon sa disenyo.

Ang encryption at pagpili ng carrier ay magkaibang katangian. Maaaring i-encrypt ang tunnel sa isang simpleng landas ng IP, at ang tunnel na dinadala ng DNS ay maaaring itayo nang may proteksyon sa payload nito o wala. Panatilihin ang HTTPS ng app sa lugar nito kahit ano pa man, at suriin ang tunay na disenyo ng seguridad ng tunnel at hindi ang pangalan nito.

Kung ang pangangailangan ay pagkapribado mula sa lokal na network, ang naka-encrypt na DNS at tunnel ng data ay sumasagot sa magkaibang bahagi nito. Isulat kung sinong tagamasid ang ipinagtatanggol mo bago pumili ng isa.

Itugma ang pagwawasto sa tunay na pagkabigo

Para sa ordinaryong mabagal na VPN, ang pagpapalit ng tunnel na dinadala ng DNS ay nagdaragdag ng limitadong transport sa ibabaw ng problema. Hindi nito inaayos ang kalidad ng radyo, pagsisikip o karga ng server, at kadalasan ay ginagawa itong mas nakikita.

Para sa mga pagkabigo ng pribadong pangalan, suriin muna ang inilaan na patakaran ng resolver: aling server ang dapat sumagot, aling mga pangalan ang saklaw, at kung pinapayagan ang client na gamitin ito. Pagkatapos pumili ng awtorisadong transport na tumutugma sa pangangailangan, at itago ang configuration ng resolver sa talaan ng pagbabago upang hindi na simulan muli ng susunod na insidente ang parehong paghahanap.

Ang checklist ay maikli: tukuyin ang kaayusan, kumpirmahin kung ano ang dinadala ng mga mensahe, sukatin ang kapasidad, pagkatapos suriin ang pagtitiwala. Anumang hakbang na hindi tumutugma sa sintomas ay nangangahulugang ang dalawa pang kaayusan ay nasa laro pa.