VPN فراہم کنندگان بدلنا: صرف IP نہیں، ہوسٹ نام کی منصوبہ بندی کریں
نیا DNS ریکارڈ موجودہ سیشنز کو منتقل نہیں کرتا۔ منصوبہ بنائیں کہ نام کون کنٹرول کرتا ہے، ہر کلائنٹ اسے کب حل کرتا ہے، اور آپ پرانے اینڈ پوائنٹ کو کیسے ریٹائر کریں گے۔
آپ کا DNS ریکارڈ درست ہے، متبادل صحت مند ہے، اور پھر بھی کچھ کلائنٹ گھنٹوں پرانے پتے پر ڈائل کرتے ہیں۔ کچھ ایسے نام پر فوراً ناکام ہوتے ہیں جو حل ہوتا ہے اور کبھی جواب نہیں دیتا۔ دونوں نتائج ایک ہی خلا سے آتے ہیں: ہوسٹ نام بدلتا ہے کہ کلائنٹ کیا ڈھونڈتا ہے، یہ نہیں کہ کب ڈھونڈتا ہے، اور یہ بھی نہیں کہ جواب آنے پر وہ کس پر بھروسہ کرتا ہے۔
علامت: درست ریکارڈ، پرانی سرنگیں
نام محفوظ کرنے والا پروفائل ایسا کلائنٹ نہیں جو اسے مسلسل حل کرتا رہے۔ زیادہ تر ایک بار حل کرتے ہیں، کنفیگریشن لاگو کرتے وقت یا سرنگ کے اوپر آنے پر، اور پھر سیشن ختم ہونے تک وہی پتہ دوبارہ استعمال کرتے ہیں۔ اس کے اوپر طویل TTL ہونا ہی سبب ہے کہ تبدیلی کی منصوبہ بندی DNS ترمیم کے بجائے دوبارہ جڑنے کے گرد کرنی پڑتی ہے۔
دونوں رویوں میں سے کوئی بھی نقص نہیں، اور یہی علامت کو الجھن بھرا بناتا ہے۔ کلائنٹ پہلے ملے جواب پر کام کر رہا ہے، اور سرور کی طرف کوئی چیز نہیں دکھاتی کہ وہ کون سا جواب تھا۔ دوبارہ جڑنے کو دیکھ بھال کی ونڈو میں شامل کریں اور صارفین کو بتائیں کہ وہ کیا دیکھیں گے، یا ونڈو ٹکٹوں کے جواب دینے میں گزاریں۔ ایک جیسی رپورٹوں کی قطار عام نتیجہ ہے۔
نام کون کنٹرول کرتا ہے، اور کلائنٹ کیا تصدیق کرتا ہے
زون پر کنٹرول طے کرتا ہے کہ منتقلی کتنی تیزی سے آگے بڑھ سکتی ہے۔ ریکارڈ ایسے رجسٹرار کے پاس رکھیں جہاں آپ لاگ ان کر سکیں، اور لکھیں کہ اور کون اسے بدل سکتا ہے۔
بھروسہ نام کے پیچھے نہیں چلتا۔ TLS پر مبنی کلائنٹ سرٹیفکیٹ کی شناخت یا پن شدہ نام جانچ سکتا ہے، جبکہ WireGuard ساتھی کی عوامی کلید کی تصدیق کرتا ہے اور ہوسٹ نام کو مکمل طور پر نظر انداز کرتا ہے۔ یہی فرق طے کرتا ہے کہ DNS ترمیم کافی ہے یا ہر پروفائل کو نئی فنگر پرنٹ چاہیے۔ ریکارڈ کی تبدیلی کو کبھی ایسے اینڈ پوائنٹ کی اجازت نہیں دینی چاہیے جسے کسی نے منظور نہ کیا ہو۔
انتظامی اور بحالی رسائی کو عوامی کلائنٹ نام سے دور رکھیں۔ ہوسٹنگ اکاؤنٹ کھونا کلائنٹوں کو ری ڈائریکٹ کرنے والا ریکارڈ بھی نہیں چھیننا چاہیے۔ بحالی کا راستہ ایسی جگہ محفوظ کریں جو اس فراہم کنندہ پر منحصر نہ ہو جسے آپ چھوڑ رہے ہیں۔
ہر کلائنٹ نام کب دوبارہ پڑھتا ہے
حل ہونے کا وقت ہر کلائنٹ کی خصوصیت ہے، اس لیے تبدیلی کی ونڈو کا وعدہ کرنے سے پہلے وہ نفاذ جانچیں جو آپ واقعی تقسیم کرتے ہیں۔ wg-quick انٹرفیس کے اوپر آنے پر اینڈ پوائنٹ حل کرتا ہے اور سرنگ دوبارہ شروع ہونے تک وہی پتہ رکھتا ہے۔ OpenVPN کلائنٹ جڑتے وقت نام ڈھونڈتا ہے، اور دوبارہ جڑنے پر دوبارہ دیکھتا ہے یا نہیں یہ اس کے اختیارات پر منحصر ہے۔
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
موبائل کلائنٹ عام حیرت ہیں، کیونکہ وہ نیند یا نیٹ ورک کی تبدیلی کے دوران حل شدہ پتہ رکھ سکتے ہیں۔ A اور AAAA ریکارڈ صرف اس وقت شائع کریں جب متبادل دونوں خاندانوں میں جواب دے۔ ایک خاندان میں جواب دینے والا پتہ دوسرے کے بارے میں کچھ ثابت نہیں کرتا، اور مردہ AAAA ریکارڈ ہر کوشش میں ایک وقت کی حد شامل کرتا ہے۔ آپ جس بھی کلائنٹ کی حمایت کرتے ہیں اس کے لیے حل کرنے کا رویہ دستاویز کریں، پھر ان آلات پر جانچیں جو لوگ واقعی استعمال کرتے ہیں۔
دوبارہ جڑنا زیادہ تر کلائنٹس میں صارف کا عمل ہے، اور سرور اسے مسلط نہیں کر سکتا۔ اس مرحلے کو دیکھ بھال کے نوٹ میں رکھیں، اس سطر کے ساتھ کہ جب ایسا ہوگا تو صارف کیا دیکھے گا۔
ثبوت کی بنیاد پر منتقل ہوں، پھر پرانے اینڈ پوائنٹ کو ریٹائر کریں
سوئچ سے پہلے متبادل پر ہر تہہ ثابت کریں: سننے والا جواب دیتا ہے، فائر وال پورٹ کو گزرنے دیتا ہے، راستے درست طریقے سے واپس آتے ہیں، نام نئے پتے پر حل ہوتا ہے، اور معلوم شناخت قبول کی جاتی ہے۔ کنکشن قبول کرنے والا سننے والا ہاتھ ملانے والے کے برابر نہیں، اس لیے پورٹ نہیں، ہاتھ ملانے کی جانچ کریں۔ موجودہ منسوخی فہرست کو کنفیگریشن کے پاس رکھیں، کیونکہ بحال شدہ بیک اپ ساتھیوں کی فہرست کو ویسا ہی دوبارہ بناتا ہے جیسا وہ تھا اور آپ کی پہلے سے بند کردہ رسائی دوبارہ کھول دے گا۔ لکھیں کہ آپ نے کس شناخت سے جانچ کی، کیونکہ «یہ کام کرتا ہے» ایسا ثبوت نہیں جسے کوئی دہرا سکے۔
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesمنتقلی کے دوران، ایک ہی شناخت کے لیے دونوں اینڈ پوائنٹس پر کنکشن کی کوششوں پر نظر رکھیں۔ پرانے پتے کے خلاف اب بھی تصدیق کرنے والا کلائنٹ ایسا پروفائل یا کیش شدہ جواب ہے جو کبھی ہلا نہیں۔ پرانے اینڈ پوائنٹ کو تاریخ والے منصوبے کے مطابق ریٹائر کریں، کیونکہ ایک شناخت قبول کرنے والی دو سروسز دو دروازے کھلے چھوڑ دیتی ہیں۔
تبدیلی کا امتحان نئے اینڈ پوائنٹ کے ذریعے ایک ایپلیکیشن سیشن ہے، پنگ نہیں۔ جب وہ سیشن کام کرے اور پرانا اینڈ پوائنٹ مکمل دوبارہ جڑنے کے چکر میں کوئی مجاز کوشش درج نہ کرے، منتقلی مکمل ہو گئی ہے۔