ایا کورني VPN سرور لپاره دینامیک DNS ته اړتیا لرئ؟

هغه کورني VPN ناکامي چې خلک مې ترې پوښتنه کوي ډېری د DNS ناکامۍ نه دي، او بیا هم لومړی د دینامیک DNS ګډون اخلي۔ مخکې له دې چې څه تنظیم کړئ، پرېکړه وکړئ چې ایا د کوربه نوم هغه برخه ده چې په رښتیا ماتېده۔ تازه کوونکی هغه وخت ریکارډ بیا لیکي چې ستاسو ISP ورکړی پته ځای بدل کړي؛ هغه نه پورټ پرانیستلی شي، نه د آپریټر NAT څخه تېرېدلی شي، او نه کولای شي یوه فعاله WireGuard ناسته پوهه کړي چې د هغې پای ټکی بدل شوی دی۔ درې شرطونه پرېکړه کوي چې دینامیک DNS ټول حل دی که یوازې د هغې یوه کرښه۔

لومړی شرط: ستاسو پته په رښتیا بدلېږي

د استوګنې پتې د عادي لاملونو له امله بدلېږي: د بریښنا له قطع کېدو وروسته مودم بیا سینک کېږي، ISP استخر بیا تنظیموي، د اوږد ځنډ وروسته نوی کرایه راځي۔ په ځینو لینونو کې دا لږ هم بدلېږي، او ما لیدلې چې یوه پته یو کال ټینګه پاتې شوې؛ سوداګریز پلانونه ډېری ثابته پته لري۔ که په دولسو میاشتو کې هېڅ نه وي بدل شوی، یو لاسي سمون وړ A ریکارډ یو ډیمون لږ دی چې ژوندی وساتل شي۔

د اټکل پر ځای اندازه یې کړئ۔ د روټر د حالت په پاڼه کې WAN پته ولولئ، بیا یې د هغه څه سره پرتله کړئ چې بهرنۍ نړۍ یې ویني۔ دا د LAN په یوه ماشین کې وچلوئ:

curl -fsS https://api.ipify.org; echo

که دواړه ارزښتونه توپیر ولري، ستاسو د روټر مخې ته څه ژباړه کوي او هېڅ د کوربه نوم تازه کول به یې سم نه کړي۔ د 100.64.0.0/10 دننه پته د آپریټر کچې NAT لپاره شریکه ساحه ده، او دا هغه عادي لامل دی چې په سمه توګه تازه شوی نوم بیا هم له بهره وخت تېرېږي۔

دویم شرط: کاروونکي بیا نوم لټوي

لنډ TTL هغه برخه ده چې خلک یې پرېږدي۔ تکراري حل کوونکي د ریکارډ TTL درناوی کوي، خو د کاروونکي سټکونه جلا کیش کوي، او هغه ټونل چې لا دمخه ولاړ دی هېڅ بیا نه حل کوي۔ د خطا موندنې پر مهال ریکارډ 60-300 ثانیو ته وټاکئ؛ دا هغه کړکۍ لنډوي چې پخوانی ځواب پکې ورکول کېږي، او نښلول شوې ناسته نه لېږدوي۔

OpenVPN هر ځل چې بیا ونښلي کرښه remote vpn.example.net 1194 بیا حل کوي، او resolv-retry infinite هغه مجبوروي چې بیا هڅه وکړي پرځای دې چې پټ شي کله چې لټون ناکام شي۔ په سرور کې float جوړه شوې ناستې ته اجازه ورکوي چې د هغه ملګري تعقیب کړي چې سرچینې پته یې بدله شوې۔ WireGuard لا روښانه دی: wg-quick up د تنظیم د تطبیق پر مهال Endpoint حل کوي، او کاروونکی یې بیا حل کوي کله چې ټونل بیا جوړ کړي، نو هغه لاس ورکول چې لا هم پر زوړ پته بریالي کېږي تر ځنډېدو پورې بریالي پاتې کېږي۔

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

دریم شرط: د ننوتلو لاره لا هم پرانیستې ده

دینامیک DNS یوازې هغه ځای بدلوي چې نوم ورته اشاره کوي او بل هېڅ نه۔ په روټر کې پورټ فوروارډینګ، په VPN کوربه کې د فایر وال قاعده او د ISP اجازه انبوډ پیکټونو ته — ټول باید د ریکارډ د اهمیت مخکې موجود وي۔ وګورئ چې فوروارډینګ چېرته نښه کوي: که دا د انټرفیس پرځای WAN پتې سره پین وي، د پتې بدلون فوروارډینګ په خاموشۍ ماتوي او تورن ریکارډ ته ورځي۔

له بهره یې ازموئ۔ هغه ټیلیفون چې په سیلولر ډاټا کې وي او Wi-Fi یې بند وي تر ټولو ارزانه ریښتینې ازموینه ده؛ په هماغه LAN کې لپ ټاپ نه۔ کله چې نوم ستاسو عامه پتې ته حل شي او روټر کې د NAT لوپ نه وي، دننه ازموینه ناکامېږي حال دا چې ریکارډ بشپړ سم دی، او دا ډېری خلک هغه ریکارډ سمون ته ورلېږي چې کله هم غلط نه و۔

کله چې درې واړه بشپړ شي څه وچلوئ

د کوچني کوربه لپاره ddclient تر ټولو لږ حیرانوونکی تازه کوونکی دی۔ لږترلږه تنظیم هغه پته خپروي چې ورکوونکی یې ویني، او دا د دوه ګوني NAT تېروتنه تر څنګ کوي:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

دا د shell لوپ پرځای هره څو دقیقې له systemd ټایمر څخه وچلوئ، او د بریالیتوب د فرض کولو پرځای د ورکوونکي ځواب ثبت کړئ۔ د اعتبار سندونه لکه کیلي وکاروئ، ځکه هغه پرېکړه کوي چې هر کاروونکی چېرته لېږل کېږي: د حساب پټنوم پرځای محدود تازه کولو ټوکن وکاروئ، فایل د 0600 حالت کې وساتئ، او تازه کول د HTTPS له لارې ولېږئ۔

له ژمنې مخکې یې تصدیق کړئ

یوه لټون تاسو ته وایي چې پاتې نړۍ څه ویني، او هغه TTL چاپوي چې باید د بدلون وروسته یې انتظار وکړئ:

dig +noall +answer vpn.example.net @1.1.1.1

هغه پته د روټر WAN پتې سره پرتله کړئ۔ که سره سمون وخوري، نوم خپله دنده کوي او هغه څه چې لا هم ناکامېږي د ننوتلو رسېدنه، یوه کیلي یا هغه کاروونکی دی چې بیا نه دی حل کړی۔ که توپیر ولري، تازه کوونکی غلط انټرفیس خپروي، ډېری ځکه چې دا د روټر پرځای د روټر شاته VPN کوربه کې چلېدلی۔

د یوې دقیقې بیرته تګ وساتئ: وروستی کارېدونکی پته او پخوانی TTL ولیکئ، تر څو د ورکوونکي د خراب ماسپښین پر مهال دواړه په لاس خپاره کړای شئ۔

کله چې ځواب نه وي

که لومړی یا دریم شرط ناکام شي، پرېکړه بدلېږي نه تنظیم۔ د آپریټر NAT شاته ستاسو عملي انتخابونه دا دي چې له ISP څخه عامه پته وغواړئ، د ننوتلو نقطه ثابتې پتې لرونکي کوچني VPS ته ولېږدئ، یا هغه پوښ وکاروئ چې خپله لیدنه ساتي۔ که پته ثابته وي، تازه کوونکی پرېږدئ: یو A ریکارډ، یو AAAA ریکارډ که IPv6 چلوئ، هماغه پورټ فوروارډینګ۔

که پته بدله شي او کاروونکي نښلول شوي پاتې شي، ریښتینی سمون په کاروونکي کې دی: د بیا نښلولو منطق او د بیا هڅې وقفه، نه ګړندی تازه کوونکی۔ دویم ورکوونکی یوازې وقفه پټوي۔

مخکې له دې چې مخکې لاړ شئ، څلور شیان په ترتیب تصدیق کړئ:

• هغه پته چې تازه کوونکی خپروي د روټر WAN پتې سره سمون خوري۔
• د ریکارډ TTL دومره لنډ دی چې بدلون په څو دقیقو کې ښکاره شي۔
• پورټ فوروارډینګ له انټرفیس سره تړلی دی، نه له ثابتې پتې سره۔
• له وروستي بدلون وروسته یو ریښتینی کاروونکی بیا نښلی او ترافیک تېر شوی۔

که څلور واړه بشپړ وي، تنظیم پرېږدئ؛ ستاسو بل ناکامي د نومونې ستونزه نه ده، بلکې کیلي یا د فایر وال قاعده ده۔ که یو ناکام شي، هغه کرښه سمه کړئ مخکې له دې چې بل حرکت کوونکی برخه ورزیاته کړئ۔ RFC 2136 پخپله د تازه کولو میکانیزم تشریح کوي، که غواړئ وګورئ چې ډیمون په تار څه اچوي۔