کیا گھریلو 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 ریکارڈ، IPv6 چلائیں تو ایک AAAA ریکارڈ، وہی پورٹ فارورڈنگ۔

اگر کلائنٹ جڑے رہتے ہوئے پتہ بدلے تو دیانت دار اصلاح کلائنٹ میں ہوتی ہے: دوبارہ رابطے کی منطق اور دوبارہ کوشش کا وقفہ، تیز تر اپ ڈیٹر نہیں۔ دوسرا فراہم کنندہ صرف وقفہ چھپاتا ہے۔

آگے بڑھنے سے پہلے چار باتیں ترتیب سے یقینی بنائیں:

• اپ ڈیٹر جو پتہ شائع کرتا ہے وہ راؤٹر کے WAN پتے سے میل کھاتا ہے۔
• ریکارڈ کا TTL اِتنا مختصر ہے کہ تبدیلی چند منٹوں میں نظر آئے۔
• پورٹ فارورڈنگ انٹرفیس سے بندھی ہے، مستقل پتے سے نہیں۔
• آخری تبدیلی کے بعد ایک حقیقی کلائنٹ دوبارہ جڑا اور ٹریفک گزری۔

اگر چاروں پورے ہوں تو ترتیب کو ویسا ہی چھوڑ دیں؛ آپ کی اگلی ناکامی نام رکھنے کا مسئلہ نہیں بلکہ چابی یا فائر وال قاعدہ ہے۔ اگر کوئی ناکام ہو تو دوسرا حرکت کرنے والا حصہ شامل کرنے سے پہلے اُس سطر کو درست کریں۔ RFC 2136 خود اپ ڈیٹ کا طریقہ کار بیان کرتا ہے، اگر آپ دیکھنا چاہیں کہ ڈیمن تار پر کیا رکھتا ہے۔