Payagan ang DNS na dumaan lamang sa iyong VPN resolver: gabay hakbang-hakbang

Sundan ang isang paghahanap ng pangalan mula sa sandaling i-type mo ito. Nagtatanong ang browser sa operating system, nagtatanong ang operating system sa resolver na pinili ng patakaran nito, at lumalabas ang query sa device sa pamamagitan ng isang interface na may isang transport. Sinasabi ng iyong disenyo ng VPN na ang sagot ay dapat magmula sa isang partikular na resolver sa isang partikular na landas. Ang agwat sa pagitan ng dalawang pahayag na iyon ang iyong kino-configure at pagkatapos ay ipinapatupad.

Hakbang 1: pangalanan ang resolver at ang landas

Isulat ang tatlong bagay bago mo hawakan ang isang firewall: ang address ng resolver, ang protocol at port na inaasahan mo, at ang interface na dapat labasan ng query. Kung wala ang listahang iyon, ang panuntunan ay haka-haka tungkol sa trapiko at hindi pagpapatupad ng isang desisyon. Maaaring magdala ang VPN ng data ng aplikasyon habang ang DNS ay sumusunod sa hiwalay na kaayusan, at hindi iyon nag-iisa ay isang pagkakamali. Ito ang nangyayari kapag walang nagsabi sa kliyente ng iba.

Ang pagpangalan sa landas nang tahasan ang pagkakaiba ng isang disenyo at aksidente. Binibigyan ka rin nito ng isang bagay na susubukan mamaya, dahil ang bawat obserbasyon ay maihahambing sa isang nakasulat na inaasahan. Itago ang listahang iyon sa ticket ng pagbabago at hindi sa ulo ng kahit sino.

Hakbang 2: ilagay ang patakaran kung saan ito tunay na nakatira

Ang pagpili ng resolver ay pag-aari ng kliyente: ang network configuration ng operating system, ang sariling mga setting ng kliyente ng VPN, o isang pinamamahalaang patakaran ng browser. Ilagay ito roon muna, gamit ang mekanismong sinusuportahan ng platform, dahil hindi mapipilit ng firewall ang isang kliyente na pumili ng resolver na hindi nito kailanman narinig. Sa isang kliyenteng may split tunnel, sabihin nang tahasan kung aling mga domain ang pumupunta sa panloob na resolver. Sa isang pinamamahalaang pulutong, ang patakaran ng browser ang kadalasang tanging lever para sa DoH, dahil maaaring piliin ng browser ang sarili nitong naka-encrypt na resolver nang hiwalay sa setting ng system.

Laktawan ito at dumiretso sa firewall, at makakakuha ka ng panuntunang nagpapahintulot sa tamang resolver kasama ng kliyenteng hindi kailanman gumagamit nito. Mukhang tama ang panuntunan at nananatiling walang laman ang mga log ng resolver, isang nakakalitong pares sa pag-debug. I-configure muna ang pagpili, pagkatapos ay ipatupad ito.

Hakbang 3: ipatupad ang landas nang makitid

Ngayon idagdag ang pahintulot ng network para sa pinahihintulutang landas: ang address ng resolver, ang protocol at port, at ang interface na dapat labasan nito. Panatilihing limitado ang panuntunan sa resolver na iyon sa halip na payagan ang lahat ng papalabas na DNS. Ang tatlong landas sa ibaba ang maaaring tahakin ng isang modernong kliyente, at ang una lamang ang sakop ng panuntunan sa port 53.

Ang pagharang sa DoH at DoT ay lehitimo; ang ipagpalagay na naharang na sila ng panuntunan sa port 53 ay hindi. Ang browser na gumagamit ng DoH ay nagreresolba ng mga pangalan sa isang landas na hindi kailanman inilarawan ng iyong panuntunan, at ang aplikasyong nagdadala ng sarili nitong resolver ay ganoon din. Isulat ang bawat landas na balak mong payagan at bawat isang balak mong tanggihan. Ang panuntunang hindi nagpangalan ng landas ay walang napagdesisyunan tungkol dito.

Hakbang 4: sundan ang pribado at pampublikong mga pangalan

Ang split DNS ay sadyang nagpapadala lamang ng mga pribadong namespace sa isang panloob na resolver habang ang mga pampublikong pangalan ay pumupunta sa ibang lugar, kaya ang higit sa isang resolver sa disenyo ay hindi pagtagas. Ang pagtagas ay isang query na dapat pumunta sa iyong resolver at nakarating sa ibang lugar, o isang hindi maabot na nilalayong landas na nagpapabagsak sa kliyente nang tahimik. Ang dalawang kasong iyon ang dapat hanapin. Sundan ang isang panloob at isang pampublikong pangalan sa ilalim ng nilalayong patakaran at itala kung aling resolver ang sumagot sa bawat isa.

Ang isang test site na nag-uulat ng iyong resolver ay isang pahiwatig, hindi patunay, dahil nakikita lamang nito ang mga query na nakarating dito. Kunin ang query sa panig ng kliyente kapag kailangan mong malaman kung aling landas talaga ang tinahak nito, pagkatapos ay ihambing ang dalawang obserbasyon. Kapag hindi sila nagtutugma, nakakita ka ng pag-urong na walang sinumang naidokumento.

Kung tama ang address ng resolver ngunit hindi maabot, ang problema ay nasa routing o pag-filter at hindi sa patakaran. Sundan ang query hanggang sa address na iyon at kumpirmahin na bumabalik ang sagot sa inaasahang interface bago baguhin ang anumang setting ng resolver.

Hakbang 5: mag-iwan ng daan pabalik

Bago higpitan ang pag-access sa DNS sa gateway, kumpirmahin ang isang paraan ng pagbawi na hindi umaasa sa pagresolba ng pangalan. Ang sirang resolver ay nagpapahirap maabot ang bawat kasangkapan sa pag-aayos, kabilang ang mga gagamitin mo upang ibalik ang pagbabago. Panatilihing bukas ang lokal na console o landas sa labas ng banda hanggang mapatunayan ang bagong patakaran. Alisin lamang ito pagkatapos na makayanan ng patakaran ang isang muling pagkonekta.

Pagkatapos ng muling pagkonekta o pag-update ng patakaran ng browser, siyasatin muli ang epektibong kalagayan, dahil parehong maaaring baguhin ang resolver nang hindi binabago ang iyong panuntunan. Ang kinakailangan ay isang kilalang tatanggap at isang protektadong landas para sa mga query, hindi isang nakapapawi na label ng resolver sa isang screenshot. Ang espesipikasyon ng RFC 8484 para sa DNS over HTTPS ang reperensya para sa naka-encrypt na landas na hindi nakikita ng iyong panuntunan sa port.