دوه‌ګونې سټیک VPN: د پتې کورنۍ کلاینټ ټاکي، نه تاسو

تونل روان دی، د IPv4 سایټونه بارېږي، او یو هوسټ‌نوم وخت تېروي. سملاسي پایله دا ده چې VPN خراب دی یا د ننوتلو معلومات غلط دي، او معمولاً هېڅ یو یې سم نه وي. نوم د IPv4 او IPv6 دواړه پتې راستنې کړې، اپلیکیشن یوه وټاکله، او یوازې یو له دغو نوماندانو کارکوونکې لاره درلوده. د ټاکلو پرېکړه کلاینټ وکړه؛ تونل یوازې هغه څه ونه پوښل چې هغه ټاکلي وو.

ټاکنه د پوښښ ژمنه نه ده

د RFC 6724 په توګه تشریح شوې اصلي پته ټاکنه پرېکړه کوي چې کله څو انتخابونه شته وي، هوسټ کومه سرچینه او منزل جوړه غوره کوي. Happy Eyeballs پر دې د نښلونې ستراتیژي ورزیاتوي: په دواړو کورنیو کې هڅې پیلوي او هغه ساتي چې لومړی ځواب ورکوي، ترڅو کارونکي د خرابې کورنۍ د وخت تېرېدو ته انتظار ونه کړي.

هیڅ یو میکانیزم لاره نه جوړوي. که ستاسو تونل یوازې IPv4 لیږدوي، AAAA نوماند لا هم یو قانوني منزل دی چې کلاینټ یې هڅه کولی شي، او ناکامي د تېروتنې په توګه نه، بلکې د ورو بارېدو په توګه ښکاري، ځکه براوزر بېرته وګرځېد. کارونکي د خراب سایټ نه، بلکې د ورو سایټ راپور ورکوي، او د ملاتړ ټکټ هغه ابهام په میراث اخلي. دا د ثابتې کورنۍ سره بیا تکرار کړئ او راپور ځانګړی کیږي.

همدا بېرته ګرځېدل لامل دی چې نښه په اپلیکیشنونو کې ناېکسان ده. براوزر ځنډ پټوي؛ د ثابتې کورنۍ سره د کمانډ کرښې کلاینټ ریښتینې ناکامي سملاسي ښیي.

هغه کورنۍ ومومئ چې غوښتنې واقعاً کارولې وه

له نوم سره پیل کړئ، نه له تونل سره. دواړه ډوله ریکارډونه وپوښتئ او ولیکئ چې څه بېرته راغلل:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

کورنۍ او منزل په خپلو یادښتونو کې وساتئ. هغه ټکټ چې وایي سایټ د VPN له لارې نه بارېږي، هیڅوک یې نشي کتلی، خو هغه ټکټ چې وایي AAAA ناکامېږي او A کار کوي، ځانګړې لارې ته اشاره کوي.

د هغې کورنۍ لپاره لاره وګورئ

د ناکامې کورنۍ لپاره له کرنل څخه وپوښتئ چې کومه لار به کاروي او د تونل له ترتیب شوو پتو سره یې پرتله کړئ. په Linux کې، ip -6 route get د منزل لپاره هغه انټرفیس او سرچینه ښیي چې به ټاکل کېدل.

بیا پخپله تونل وګورئ. WireGuard همکاران د اجازه ورکړل شوو IP لړلیک لري، او 0.0.0.0/0 لپاره ننوتنه د IPv6 په اړه هېڅ نه وایي. که د همکار په لړلیک کې IPv6 مختاړی نه وي، کلاینټ هېڅ دلیل نه لري چې AAAA ترافیک تونل ته واستوي، او پاکټ هغې لارې وځي چې هوسټ به بل ډول تله.

د اورېدې دیوال قواعد او د NAT پالیسي د هرې کورنۍ لپاره ورته کتنې وړ دي. د IPv4 لپاره لیکل شوی قاعده په هېڅ پلیټفورم کې IPv6 نه پوښي، او دا ترټولو عام لامل دی چې یوه کورنۍ کار کوي او بله نه.

د سکرین‌شاټ ساده کولو لپاره IPv6 مه بندوئ

په ټول سیستم کې IPv6 بندول به نښه ورکه کړي او تاسو به پرته له تشخیص پاتې شئ. دا هغه هر منزل هم ماتوي چې یوازې IPv6 وي، او هماغه بګ د بل اپلیکیشن لپاره پټوي. که یو ماشین واقعاً باید IPv6 ونه کاروي، دا د مالک او ازموینې سره قصدي پالیسي ده. د یوې پېښې پر مهال یې بندول هېڅ یو نه دی.

پرېکړه وکړئ چې کلاینټ د کورنۍ سره څه وکړي او دا په څرګند ډول ترتیب کړئ: له تونل څخه یې تېر کړئ، یا په ملاتړ شوې طریقه یې بند کړئ ترڅو ټاکنه هېڅکله د نه رسېدو وړ نوماند وړاندې نکړي. دواړه قانوني ډیزاینونه دي. نړیوال بندول هېڅ یو نه دی، ځکه چې دا اصلاً ډیزاین نه دی.

په ټکټ کې څه ولیکو

څلور شیان ثبت کړئ: د هوسټ نوم، هغه کورنۍ چې ناکامه شوه، هغه لاره چې کرنل وټاکله، او د کورنۍ ځانګړې غوښتنې پایله. دا ټولګه بل چاته د ناکامۍ بیا تکرار لپاره بس ده، پرته له دې چې اټکل وکړئ کومه دوه لارې مو په نظر کې وې.

د RFC 6724 د پتې ټاکنې قواعد تشریح کوي چې کلاینټ ولې هغه نوماند غوره کړ چې غوره کړ، او RFC 8305 د سیالۍ هغه چلند تشریح کوي چې ځنډ یې پټ کړ. هېڅ یو به ستاسو لپاره پاکټ لار نه ښیي، او دا هغه برخه ده چې تونل یې باید وکړي.