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

نښه: سم ریکارډ، زاړه تونلونه

هغه پروفایل چې نوم ساتي هغه کلاینټ نه دی چې تل یې حل کوي۔ ډېری یې یو ځل حل کوي، د ترتیباتو د پلي کولو پر مهال یا کله چې تونل پورته شي، او بیا تر غونډې پای پورې هغه پته بیا کاروي۔ پر دې باندې اوږد TTL ایښودل هغه لامل دی چې ولې بدلون باید د بیا نښلولو شاوخوا پلان شي، نه د DNS سمون شاوخوا۔

له دواړو چلندونو څخه هیڅ یو هم نقص نه دی، او همدا نښه ګډوډوي۔ کلاینټ د هغې ځواب پر بنسټ کار کوي چې مخکې یې ترلاسه کړی و، او د سرور په اړخ کې هېڅ شی نه ښیي چې هغه کوم ځواب و۔ بیا نښلول د ساتنې په کړکۍ کې شامل کړئ او کاروونکو ته ووایاست چې څه به وویني، یا کړکۍ د ټیکټونو ځواب ورکولو ته ورکړئ۔ د ورته راپورونو قطار معمول پایله ده۔

نوم څوک کنټرولوي، او کلاینټ څه تصدیق کوي

پر زون کنټرول ټاکي چې مهاجرت څومره ژر پرمخ تلای شي۔ ریکارډ د هغې راجستر کوونکې سره وساتئ چې تاسو ورته ننوځئ، او ولیکئ چې بل څوک یې بدلولای شي۔

باور د نوم پسې نه ځي۔ د TLS پر بنسټ کلاینټ کولای شي د سند هویت یا پین شوی نوم وګوري، په داسې حال کې چې WireGuard د سیال عامه کیلي تصدیقوي او د کوربه نوم په بشپړه توګه له پامه غورځوي۔ همدا توپیر ټاکي چې د DNS سمون کافي دی که هر پروفایل نوی نښان ته اړتیا لري۔ د ریکارډ بدلون باید هېڅکله هغه پای ټکی واک ورنکړي چې چا نه وي تصویب کړی۔

اداري او بیا رغونې لاسرسی د عامه کلاینټ نوم څخه لرې وساتئ۔ د هوسټینګ حساب له لاسه ورکول باید هغه ریکارډ هم له لاسه ورنکړي چې کلاینټونه ریډایرکټ کوي۔ د بیا رغونې لاره په داسې ځای کې وساتئ چې د هغې چمتو کوونکې پورې تړلې نه وي چې تاسو یې پرېږدئ۔

هر کلاینټ نوم کله بیا لولي

د حل وخت د هر کلاینټ ځانګړنه ده، نو د بدلون د کړکۍ ژمنې کولو دمخه هغه پلي کول وګورئ چې تاسو یې واقعاً وړاندې کوئ۔ wg-quick هغه وخت پای ټکی حل کوي چې انټرفیس پورته شي او هغه پته تر هغه ساتي چې تونل بیا پیل شي۔ OpenVPN کلاینټ د نښلولو پر مهال نوم لټوي، او دا چې د بیا نښلولو پر مهال به بیا وګوري که نه، د هغې د انتخابونو پورې اړه لري۔

ClientWhen it resolvesWhat it verifies
wg-quickAt interface start, cached for the sessionPeer public key, not the name
OpenVPN 2.6On connect, possibly again on reconnectCertificate identity or pinned name
Mobile clientsMay hold the answer across sleep or a network changePlatform trust store, same certificates

د موبایل کلاینټونه معمول حیرانتیا ده، ځکه چې دوی کولای شي د خوب یا شبکې بدلون په اوږدو کې حل شوې پته وساتي۔ A او AAAA ریکارډونه یوازې هغه وخت خپاره کړئ چې بدیل په دواړو کورنیو کې ځواب ووایي۔ هغه پته چې په یوه کورنۍ کې ځواب وایي د بلې په اړه هېڅ نه ثابتوي، او مړ AAAA ریکارډ هر هڅې ته د وخت حد زیاتوي۔ د هر هغه کلاینټ لپاره چې تاسو یې ملاتړ کوئ د حل چلند مستند کړئ، بیا پر هغو وسایلو ازموینه وکړئ چې خلک یې واقعاً کاروي۔

بیا نښلول په ډېرو کلاینټونو کې د کاروونکي عمل دی، او سرور نه شي کولای چې یې مجبور کړي۔ هغه ګام د ساتنې یادښت کې کېږدئ، د یوې کرښې سره چې کاروونکی به څه وویني کله چې دا پېښ شي۔

پر شاهدو بدلون وکړئ، بیا زوړ پای ټکی تقاعد کړئ

د بدلون دمخه پر بدیل باندې هر پوړ ثابت کړئ: اورېدونکی ځواب وایي، فایر وال پورت تېروي، لارې سمې بېرته راځي، نوم نوي پتې ته حل کېږي، او پېژندل شوی هویت منل کېږي۔ هغه اورېدونکی چې اړیکه مني هغه نه دی چې لاس ورکول بشپړوي، نو پورت نه، لاس ورکول وآزمویئ۔ اوسنی لغوه کولو لیست د ترتیباتو ترڅنګ وساتئ، ځکه بیا رغول شوی بیک اپ د سیالانو لیست بیا هغسې جوړوي لکه چې و، او هغه لاسرسی به بیا پرانیزي چې تاسو مخکې تړلی و۔ ولیکئ چې په کوم هویت مو ازموینه وکړه، ځکه «کار کوي» هغه شاهد نه دی چې څوک یې تکرار کولای شي۔

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

د بدلون په جریان کې، د یو هویت لپاره پر دواړو پای ټکو د نښلولو هڅې وګورئ۔ هغه کلاینټ چې لا هم د زاړه پتې پر وړاندې تصدیق کوي پروفایل یا کیش شوی ځواب دی چې هېڅکله نه دی خوځېدلی۔ زوړ پای ټکی د نېټې لرونکې پلان له مخې تقاعد کړئ، ځکه دوه خدمتونه چې یو هویت مني دوه دروازې پرانیستې پرېږدي۔

د بدلون ازموینه د نوي پای ټکي له لارې د اپلیکیشن غونډه ده، نه ping۔ کله چې هغه غونډه کار وکړ او زوړ پای ټکی په بشپړ بیا نښلولو دوره کې هېڅ مجاز هڅه ثبت نه کړي، لېږد بشپړ شوی۔

اړوندې مقالې