له VPN پرته کوډ شوی DNS پوښتنه پټوي، نه ستاسو پته

ستاسو کورني شبکه ښودونکی DNS لیک ټیسټ د دې شاهدي نه ده چې کوډ شوی DNS ناکام شو، او د دې هم شاهدي نه ده چې یو څه کار وکړ. ټیسټ یوې پوښتنې ته ځواب وایي: دا پوښتنه له دې شبکې څخه کوم حل کوونکي ته ورسېده. دا ستونزه ده که نه، په دې پورې اړه لري چې تاسو له څه او له چا څخه ساتنه کوله.

له هرې ازموینې دمخه هدف ولیکئ.

ګام 1: هغه ساتنه ونوموئ چې واقعاً یې غواړئ

درې هدفونه یو ځای کېږي. کېدای شي وغواړئ چې په لاره کې یو څارونکی د پوښتنو لوستل بند کړي. کېدای شي وغواړئ چې یو ځانګړی حل کوونکی هغه ترلاسه کول بند کړي. کېدای شي وغواړئ چې هغه وېبپاڼې چې تاسو یې ګورئ ستاسو کورنۍ پته لیدل بند کړي. کوډ شوی DNS لومړي ته خدمت کوي، بدلوي چې دویم څوک پوره کوي، او د دریم لپاره هېڅ نه کوي.

VPN دریم ته خدمت کوي او د برابرونکي له مخې لومړي ته هم. هېڅ وسیله د بل سوپر سیټ نه ده.

ګام 2: یو حل کوونکی وټاکئ او هویت یې تایید کړئ

DNS over TLS پوښتنه د حل کوونکي سره په TLS ناسته کې نغاړي، او DNS over HTTPS هغه په HTTP غوښتنه کې نغاړي؛ RFC 7858 او RFC 8484 دواړه بیانوي، او هېڅ یو تونل ته اړتیا نه لري. عملیاتي مهمه دا ده چې سند د هغه نوم سره تایید شي چې تاسو تنظیم کړی، ځکه له غلط لوري سره کوډ شوې ناسته له سم لوري سره له ساده متن څخه بدتره ده. دا پدې مانا ده چې چېرې پلیټفارم وړاندې کوي هلته سخت حالت، نه هغه فرصتپال حالت چې تایید ناکام شي نو شاته ځي. له تنظیم باور کولو دمخه ناسته مستقیم وګورئ: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

لاس ورکول باید هغه حل کوونکی ونوموي چې تاسو تنظیم کړی او داسې زنځیر بېرته راوړي چې تاسو یې تایید کولی شئ.

ګام 3: د ناکامۍ چلند وټاکئ

هر پلي کول د نه رسېدونکي کوډ شوي حل کوونکي لپاره تګلاره لري، او هغه تګلاره د محرمیت پرېکړه ده. سخت حالت لټون ناکاموي، چې ښکاره او ستړي کوونکی دي. فرصتپال حالت په ساده متن کې بیا هڅه کوي، چې نه ښکاري او په هغه ورځ چې اهمیت لري هدف له منځه وړي. په پوهاوي سره وټاکئ، بیا انتخاب د اړتیا ترڅنګ ولیکئ.

په systemd-resolved کې فرصتپال حالت نه، DNSOverTLS=yes غوره کړئ؛ بل ارزښت، opportunistic؛ او په Android کې مانا ده چې د اتوماتیک پرځای Private DNS د کوربه نوم حالت.

وګورئ چې واقعاً څه نافذ دي په دې سره: resolvectl status | grep -i -A1 "dns over tls", ځکه هغه drop-in فایل چې هېڅکله بیا نه دی لوستل شوی هېڅ نه بدلوي.

ګام 4: وګورئ چې اپلیکیشنونه د سیستم حل کوونکي پیروي کوي

هغه براوزر چې خپله خوندي-DNS تنظیم لري د سیستم ترتیب په بشپړه توګه پرېږدي، او همدارنګه هغه کنټینر رنټایم چې دننه حل کوونکی لري یا هغه ژبني رنټایم چې سخت کوډ شوی لیست لولي. یا یې د سیستم پیروي ته اړ کړئ یا یې په څرګنده تنظیم کړئ او ولیکئ. بیا د هر یوه د شاتګ چلند وګورئ، ځکه ټول په بند ډول ناکام نه شي. لیست په عمل کې لنډ دی: براوزر، کنټینر رنټایم، او هر هغه VPN پیرودونکی چې تاسو یې هم چلوئ.

د سازمان شخصي نومونه په تصویب شوي داخلي حل کوونکي پاتې کېږي. دوی عامه خدمت ته لېږل ترڅو ټیسټ منظم ښکاره شي په قصد سره بله ستونزه جوړوي.

ګام 5: لیک ټیسټ د اړتیا په وړاندې ولولئ

هغه ټیسټ چې ناڅاپي حل کوونکی راپور کوي نښه ده، نه پرېکړه. کېدای شي ستاسو هغه کوډ شوی حل کوونکی، د اپلیکیشن ځانګړی تنظیم، یا ساده متن ته هغه شاتګ لیدلی وي چې تاسو نه پوهېدل. راپور شوی حل کوونکی له هغه سره پرتله کړئ چې ګام 2 تنظیم کړی، او پایله له ګام 1 هدف سره پرتله کړئ.

که هدف دا و چې پوښتنې له سیمه ییزې شبکې لرې وساتئ، نو هغه ټیسټ چې ستاسو عادي حل کوونکی ښیي ریښتینی موندنه ده. که هدف د لټون پر مهال بېنامي وه، نو هېڅ DNS تنظیم به دا هېڅکله نه وړاندې کړی.

د منلو کرښه د هدف په ژبه ولیکئ: دا لټونونه دا تایید شوی حل کوونکی د دې شرایطو لاندې کاروي. له دې پراختر هر څه هغه ادعا ده چې تاسو یې ازموینې نشئ کولی.