VPN سرور کو نئے عوامی IP پر منتقل کرنا: پہلے کیا جانچیں
جگہ پر تبدیلی اور متوازی منتقلی مختلف جگہوں پر ٹوٹتی ہے۔ ترتیبات، NAT اور سرٹیفکیٹ دیکھیں، پھر دیکھیں کہ ہر کلائنٹ نام کو کیسے حل کرتا ہے۔
پتہ دوبارہ تفویض کرنے میں ایک منٹ لگتا ہے۔ اگلا ہفتہ وہ جگہ ہے جہاں منتقلی ٹوٹتی ہے، اور شاذ و نادر ہی وہاں جہاں فراہم کنندہ کا کنسول اشارہ کرتا ہے۔ نیا عوامی IP چار جگہوں پر مذکور ہوتا ہے: وہ ساکٹ جس پر ڈیمون سنتا ہے، وہ اعتماد لنگر جسے کلائنٹ تصدیق کرتے ہیں، پرانے پتے کا نام لینے والا ہر قاعدہ، اور وہ DNS ریکارڈ جو انہیں جوڑتا ہے۔ دو منتقلیاں کنٹرول پینل سے ایک جیسی لگتی ہیں مگر بالکل مختلف برتاؤ کرتی ہیں: جس مشین کو آپ چلاتے ہیں اس پر پتہ دوبارہ تفویض کرنا، یا دوسرا اینڈ پوائنٹ کھڑا کر کے کلائنٹ وہاں منتقل کرنا۔ نیچے کی جانچیں سستے نقصانات کو پہلے رکھتی ہیں، اور ہر حصہ بتاتا ہے کہ کون سی منتقلی پر لاگو ہے۔
جگہ پر تبدیلی اور متوازی منتقلی مختلف کام ہیں
جگہ پر تبدیلی میزبان، کلیداں، روٹنگ جدول اور صارف فہرست رکھتی ہے؛ صرف پتہ بدلتا ہے۔ تیرتا IP دوبارہ تفویض کرنا یہی کرتا ہے، اور کئی فراہم کنندگان پر مہمان کو کچھ پتہ نہیں چلتا، کیونکہ ترجمہ مثال کے سامنے ہوتا ہے۔ دوبارہ تعمیر یا فراہم کنندہ کی دوبارہ تفویض زیادہ سخت ہے: مہمان تبدیلی دیکھتا ہے، اور جس نے بھی پرانی قدر محفوظ کی تھی وہ اسی لمحے اسے جان لیتا ہے۔
متوازی اینڈ پوائنٹ دوسرا میزبان ہے جو وہی کام کرتا ہے۔ اسے بنائیں، ایک پروفائل سے جانچیں، اور نئے کو حقیقی راستے پر خود کو ثابت کرنے تک پرانے کو جواب دینے دیں۔ قیمت حالت ہے۔ مشترکہ peer اندراجات، منسوخیوں اور لاگنگ کے بغیر آپ کے پاس دو نیٹ ورک ہیں جو اتفاقاً ایک ہی نام بانٹتے ہیں۔
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
پرانا پتہ جہاں بھی لکھا ہے وہ ہر جگہ تلاش کریں
متن کی تلاش سے شروع کریں، کیونکہ ترتیباتی فائلیں آسان آدھا حصہ ہیں۔ ڈیمون ترتیبات، فائر وال کے ٹکڑے، نگرانی کے اہداف اور ڈسک پر بنایا گیا کوئی بھی کلائنٹ بنڈل تلاش کریں۔ IPv6 پتہ بھی شامل کریں اگر آپ ایسا شائع کرتے ہیں؛ صرف A ریکارڈ کی پیروی کرنے والی منتقلی دوہرے اسٹیک کلائنٹ کو پرانے راستے پر چھوڑ دیتی ہے۔
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsپھر کرنل کا جائزہ لیں، کیونکہ چلتا ہوا نظام پتہ ایسی جگہوں پر رکھتا ہے جن کا کوئی فائل ذکر نہیں کرتا۔ مستقل ماخذ NAT قاعدہ، ipset اندراج، bind پتہ اور conntrack اندراج انہیں ہٹانے والی ترتیب کی تبدیلی سے زیادہ زندہ رہتے ہیں، اور کچھ ری بوٹ بھی پار کر جاتے ہیں کیونکہ وہ محفوظ قواعد کے مجموعے سے واپس آئے۔ ایک سطح اوپر، فراہم کنندہ کے سیکیورٹی گروپس، لوڈ بیلنسر کے اہداف اور نگرانی کی جانچیں آپ کے فائل سسٹم پر ہی نہیں ہیں۔
کچھ بھی بدلنے سے پہلے فہرست لکھیں؛ یہ رول بیک اسکرپٹ کا کام بھی کرتی ہے۔
میزبان نام والے کلائنٹ سنبھل جاتے ہیں؛ لفظی IP والے کلائنٹ خاموش ہو جاتے ہیں
اگر کلائنٹ میزبان نام کے ذریعے سرور تک پہنچتے ہیں، تو منتقلی بنیادی طور پر DNS مسئلہ ہے، اور کل جو TTL آپ نے مقرر کیا وہ طے کرتا ہے کہ یہ کتنا خراب ہوگا۔ حل کرنے والے کیش کرتے ہیں، stub حل کرنے والے دوبارہ کیش کرتے ہیں، اور بہت سے کلائنٹ نام صرف نئی کنکشن پر ڈھونڈتے ہیں، اس لیے قائم شدہ سرنگ اپنا ابتدائی پتہ رکھتی ہے۔
اگر اینڈ پوائنٹ لفظی پتہ ہے، تو کچھ دوبارہ حل نہیں ہوتا اور کوئی شکایت درج نہیں کرتا۔ WireGuard حل شدہ ساکٹ پتہ محفوظ کرتا ہے: Endpoint = vpn.example.net:51820 اسی لمحے IP بن جاتا ہے جب wg-quick up چلتا ہے اور اسی IP پر رہتا ہے جب تک آپ اسے نہ بدلیں۔ OpenVPN زیادہ روادار ہے: یہ کنکشن کے وقت remote میزبان نام حل کرتا ہے اور resolv-retry infinite کے ساتھ دوبارہ جڑنے پر پھر DNS آزماتا ہے۔ لفظی IP دینے پر دونوں ایسی مشین کو ڈائل کرتے رہتے ہیں جو اب موجود نہیں۔
لوگوں کو دھوکہ دینے والی چیز آئینے کی تصویر ہے۔ نئے پتے کی طرف پہلے سے اشارہ کرنے والا کلائنٹ، جب پرانا سننے والا ابھی جواب دے رہا ہو، آپ کی اپنی میز سے کی گئی ہر جانچ پاس کر جاتا ہے۔ مجھے بھی اسی نے دھوکہ دیا: نیا اینڈ پوائنٹ فون پر پہلی کوشش میں اوپر آیا، اور پرانے پروفائل والا کلائنٹ تبھی سامنے آیا جب پرانا سننے والا بہت بعد میں بند کیا گیا۔
اعتماد پتے کے ساتھ منتقل نہیں ہوتا
WireGuard شناخت کو رسائی سے الگ کرتا ہے، جو پتہ منتقل کرنے کو تقریباً مفت بنا دیتا ہے۔ peer عوامی کلید سے پہچانے جاتے ہیں، اور اینڈ پوائنٹ صرف وہ جگہ ہے جہاں پیکٹ ابھی جاتے ہیں؛ میزبان آخری تصدیق شدہ پیکٹ کے ماخذ پتے سے peer کا اینڈ پوائنٹ اپ ڈیٹ کرتا ہے۔ غیر فعال peer کو پھر بھی نئی جگہ سے بات کرنے کی وجہ درکار ہوتی ہے، اور وہ پتہ تبھی سیکھتا ہے جب اس کا سیشن پرانا ہو جائے اور handshake کی دوبارہ کوششیں کہیں نظر آنے والی جگہ پر ناکام ہوں۔ WireGuard کی فوری رہنمائی اینڈ پوائنٹ فیلڈ کا احاطہ کرتی ہے۔
TLS پر مبنی سرور الٹ معاملہ ہیں۔ سرٹیفکیٹ ایک نام سے بندھا ہے، اور پتہ ڈائل کرنے والا کلائنٹ جو ڈائل کیا اس کا موازنہ موضوع کے متبادل ناموں سے کرتا ہے۔ صرف DNS SAN والے سرٹیفکیٹ سے IP کے ذریعے جڑیں اور تصدیق ناکام ہو جاتی ہے: کلائنٹ کا استعمال کردہ نام سرٹیفکیٹ میں نہیں ہے۔ IP SAN کے ساتھ دوبارہ جاری کرنا اس ایک کنکشن کو درست کرتا ہے اور اگلی منتقلی کو بدتر بناتا ہے۔ پروفائل میں میزبان نام رکھنا اور verify-x509-name کو اس کی جگہ چھوڑنا جانچ کو سخت رکھتا ہے جبکہ نیچے کا پتہ بدلتا رہتا ہے۔
پھر جانچیں کہ ڈیمون کس سے بندھا ہے؛ پرانے پتے پر پن کیا گیا ساکٹ خاموشی سے ناکام ہوتا ہے۔ local 203.0.113.10 کے ساتھ شروع کیا گیا OpenVPN سرور اس پتے کے جانے پر اوپر آنے سے انکار کر دیتا ہے، جبکہ 0.0.0.0 پر سننے والا تبدیلی مفت میں اپناتا ہے۔ NAT بھی اسی طرح بٹتا ہے: MASQUERADE اب مشین کے پاس جو بھی پتہ ہے اس کی پیروی کرتا ہے، اور مستقل SNAT --to-source 203.0.113.10 اس پتے پر دوبارہ لکھتا رہتا ہے جو اب آپ کا نہیں، اس لیے واپسی ٹریفک غائب ہو جاتی ہے۔ اگر نیا پتہ مختلف upstream گیٹ وے کے ساتھ آتا ہے تو rp_filter جانچیں: معکوس راستے کی فلٹرنگ اس انٹرفیس پر آنے والی واپسی ٹریفک گرا دیتی ہے جس کی کرنل کو توقع نہ تھی۔
منتقلی کی ترتیب اور اس کے کام کرنے کے ثبوت
ایک دن پہلے TTL کم کریں، نیا سننے والا کھڑا کریں، اور ایسی پروفائل سے اسے ثابت کریں جو صرف آپ کے پاس ہو۔ اسی نیٹ ورک کے اندر سے جانچ تقریباً کچھ ثابت نہیں کرتی، اس لیے سیلولر پر فون استعمال کریں اور اینڈ پوائنٹ پر ping کے بجائے وہ چیز جانچیں جو سرنگ کو ڈھونی ہے۔
پوری مدت میں دونوں پتوں پر نظر رکھیں۔ نئے میزبان پر wg show all latest-handshakes، یا OpenVPN کی حالت فائل، بتاتی ہے کہ واقعی کتنے peer منتقل ہوئے۔ جب نئے اینڈ پوائنٹ پر متوقع peer ہوں اور پرانے پر صرف پیچھے رہ جانے والے، تو پرانے سننے والے کو ریٹائر کریں، پرانا NAT قاعدہ ہٹائیں اور فراہم کنندہ کے فائر وال سے پتہ نکالیں۔ پرانے سننے والے کو ہٹانا ہی وہ قدم ہے جو چھوٹ جاتا ہے، اور یہ وہ خلا بند کرتا ہے جہاں پرانی پروفائل اب بھی پرانے نیٹ ورک تک پہنچتی ہے۔
شروع کرنے سے پہلے رول بیک ٹرگر تحریری طور پر طے کریں: اگر طے شدہ مدت کے بعد نئے اینڈ پوائنٹ کو کسی بھی حقیقی کلائنٹ سے handshake نہ ملے، تو پرانا پتہ بحال کریں اور پروفائل تقسیم کرنا بند کریں۔ پھر تلاش دوبارہ چلائیں اور تصدیق کریں کہ کوئی سننے والا اب بھی ریٹائر شدہ پتے سے بندھا نہیں۔ دو چیزیں اگلی منتقلی میں جاتی ہیں: کلائنٹ پروفائل میں میزبان نام تاکہ اگلی تبدیلی DNS ترمیم ہو، اور سرور کے بازیابی نوٹس کے پاس رکھی گئی فہرست۔