DNS iliyosimbwa bila VPN huficha swali, sio anwani yako

Jaribio la uvujaji wa DNS linaloonyesha mtandao wako wa nyumbani si uthibitisho kwamba DNS iliyosimbwa imeshindwa, na si uthibitisho kwamba kitu kimefanya kazi. Jaribio hujibu swali moja: ni kitatuzi kipi kilipokea swali hili kutoka mtandao huu. Ikiwa hilo ni tatizo linategemea ulichokuwa ukilinda na kutoka kwa nani.

Andika lengo kabla ya kuendesha jaribio lolote.

Hatua 1: taja ulinzi unaoutaka kwa kweli

Malengo matatu yanachanganyika. Huenda unataka mwangalizi aliye njiani aache kusoma maswali. Huenda unataka kitatuzi fulani kiache kupokea maswali hayo. Huenda unataka tovuti unazozitembelea ziache kuona anwani yako ya nyumbani. DNS iliyosimbwa hutumikia la kwanza, hubadilisha nani anayetimiza la pili, na haifanyi chochote kwa la tatu.

VPN hutumikia la tatu na, kulingana na mtoa huduma, la kwanza. Hakuna chombo ambacho ni seti kuu ya kingine.

Hatua 2: chagua kitatuzi na uthibitishe utambulisho wake

DNS over TLS hufunika swali katika kikao cha TLS na kitatuzi, na DNS over HTTPS hukifunika katika ombi la HTTP; RFC 7858 na RFC 8484 hueleza zote mbili, na hakuna inayohitaji handaki. Kinachohimika kiutendaji ni kwamba cheti huthibitishwa dhidi ya jina uliloweka, kwa sababu kikao kilichosimbwa na upande usiofaa ni mbaya zaidi kuliko maandishi wazi na ule sahihi. Hii inamaanisha hali kali pale jukwaa linapotoa, sio hali ya kubahatisha inayorudi nyuma uthibitisho unaposhindwa. Kagua kikao moja kwa moja kabla ya kuamini mpangilio: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Kupeana mikono kunapaswa kutaja kitatuzi ulichokiweka na kurudisha mnyororo unaoweza kuuthibitisha.

Hatua 3: amua tabia wakati wa kushindwa

Kila utekelezaji una sera kwa kitatuzi kilichosimbwa kisichofikika, na sera hiyo ni uamuzi wa faragha. Hali kali hufanya utafutaji ushindwe, jambo ambalo linaonekana na linasumbua. Hali ya kubahatisha hujaribu tena kwa maandishi wazi, jambo ambalo halionekani na huharibu madhumuni siku ile ile inapojalizwa. Chagua kwa makusudi, kisha andika chaguo kando ya hitaji.

Kwenye systemd-resolved, hali ya kubahatisha si chaguo, DNSOverTLS=yes inahitajika; thamani nyingine, opportunistic; na kwenye Android inamaanisha hali ya jina la mwenyeji la Private DNS badala ya kiotomatiki.

Kagua kinachotekelezwa kweli kwa resolvectl status | grep -i -A1 "dns over tls", kwa sababu faili ya drop-in ambayo haikupakiwa upya kamwe haibadilishi chochote.

Hatua 4: kagua ikiwa programu zinafuata kitatuzi cha mfumo

Kivinjari kilicho na mpangilio wake wa DNS salama hukwepa usanidi wa mfumo kabisa, na vilevile runtime ya kontena iliyo na kitatuzi kilichopachikwa au runtime ya lugha inayosoma orodha iliyowekwa kwa bidii. Ama zifanye zifuate mfumo au zisanidi kwa uwazi na uandike hilo. Kisha angalia tabia ya kurudi nyuma ya kila moja, kwa sababu sio zote hushindwa kwa kufungwa. Orodha kwa vitendo ni fupi: kivinjari, runtime ya kontena, na mteja wowote wa VPN unaoendesha pia.

Majina ya faragha ya shirika hubaki kwenye kitatuzi cha ndani kilichoidhinishwa. Kuyatuma kwa huduma ya umma ili jaribio lionekane safi huunda tatizo lingine kwa makusudi.

Hatua 5: soma jaribio la uvujaji dhidi ya hitaji

Jaribio linaloripoti kitatuzi kisichotarajiwa ni kidokezo, sio hukumu. Huenda limeona kitatuzi chako kilichosimbwa ulichokusudia, mpangilio maalum wa programu, au kurudi nyuma kwa maandishi wazi usingelijua. Linganisha kitatuzi kilichoripotiwa na kile hatua 2 ilichokiweka, na linganisha matokeo na lengo la hatua 1.

Ikiwa lengo lilikuwa kuweka maswali mbali na mtandao wa karibu, jaribio linaloonyesha kitatuzi chako cha kawaida ni ugunduzi wa kweli. Ikiwa lengo lilikuwa kutokujulikana wakati wa kuvinjari, hakuna mpangilio wa DNS ambao ungeweza kutoa hilo.

Andika mstari wa kukubali kwa lugha ya lengo: utafutaji huu hutumia kitatuzi hiki kilichothibitishwa chini ya masharti haya. Kitu chochote kilicho pana zaidi ni dai ambalo huwezi kulijaribu.