کیا آپ کو لگتا ہے کہ Pritunl سرور کا نام بدلنے سے اس کا اینڈ پوائنٹ بدل جاتا ہے؟

Pritunl سرور کا نام بدلنے سے کنسول میں ایک لیبل بدلتا ہے۔ یہ اس پتے کو نہیں بدلتا جس سے کلائنٹ پروفائل جڑتے ہیں، اور DNS ریکارڈ نہیں بناتا۔ اہم قیمت ہوسٹ کا عوامی پتہ ہے، اور وہ پتے کی طرح نام بھی آسانی سے قبول کرتا ہے۔

جس نام سے کلائنٹ جڑتے ہیں وہ ہوسٹ کے ایک ہی فیلڈ میں رہتا ہے

Pritunl ہوسٹ کی عوامی پتہ ترتیب کے ذریعے اینڈ پوائنٹ ظاہر کرتا ہے، جو عوامی IP پتہ یا DNS نام قبول کرتی ہے۔ وہاں vpn.example.net رکھیں، اور بنے ہوئے پروفائلز اور تصدیق شدہ سنک وہ نام کلائنٹ کو دیں گے۔ ریکارڈ پہلے سے موجود ہونا چاہیے اور VPN ٹرانسپورٹ قبول کرنے والے سننے والے کی طرف حل ہونا چاہیے؛ یہ فیلڈ منزل کا اعلان کرتی ہے، اسے شائع نہیں کرتی۔ سرور آبجیکٹ کا دکھایا گیا نام انتظامی میٹاڈیٹا ہے اور کبھی کلائنٹ کی کنکشن کوشش تک نہیں پہنچتا۔

اس لیے پہلا قدم کسی چیز کا نام بدلنا نہیں ہے۔ ہوسٹ ترتیبات کھولیں، عوامی پتہ بدلیں، اور معاون انٹرفیس سے محفوظ کریں۔

تین فیلڈز جو ایک جیسی دکھتی ہیں اور نہیں ہیں

مقامی پتہ Pritunl ہوسٹوں کے درمیان نقل اور روٹنگ کے لیے کام کرتا ہے۔ لنک پتہ بتاتا ہے کہ منسلک سرور ایک دوسرے تک کیسے پہنچتے ہیں۔ دونوں میں سے کوئی وہ پتہ نہیں جس سے کلائنٹ جڑتا ہے، اور عوامی نام ان میں نقل کرنے سے وہ ٹوپولوجی ٹوٹ جاتی ہے جسے یہ بیان کرتے ہیں۔ عوامی IPv6 پتہ اپنے ریکارڈ اور راستے والی الگ فیلڈ ہے؛ IPv4 کے لیے A ریکارڈ IPv6 رسائی قائم نہیں کرتا۔

DNS نام بھی کوئی پورٹ میپنگ یا سننے والا نہیں رکھتا۔ اگر سروس 1194 UDP پر سنتی ہے، نام پھر بھی ایسے ہوسٹ کی طرف حل ہوتا ہے جسے 1194 UDP قبول کرنا ہے۔ پورٹ 443 پر HTTP ریورس پراکسی جو ویب کنسول فراہم کرتی ہے وہ VPN ٹرانسپورٹ کا اینڈ پوائنٹ نہیں ہے، چاہے دونوں ایک ہی نام شیئر کریں۔

ٹنل کے اندر ڈومین کی بنیاد پر روٹنگ ایک اور الگ تہہ ہے۔ بیرونی اینڈ پوائنٹ کا نام دینا اس بارے میں کچھ نہیں کہتا کہ کلائنٹ کن نجی منزلوں تک پہنچ سکتا ہے۔

نیا نام موجود کلائنٹ کو بھیجیں

فیلڈ بدلنے سے پہلے ہی سرور چھوڑ چکے پروفائلز دوبارہ نہیں لکھے جاتے۔ Pritunl کی تصدیق شدہ کنفیگریشن سنک ہوسٹ پتے اور پورٹ کی تبدیلیاں موزوں کلائنٹ تک پہنچا سکتی ہے، اور دستاویزی CLI کلائنٹ جڑنے یا دوبارہ جڑنے سے پہلے سنک کرتا ہے۔ NetworkManager یا آزاد OpenVPN کلائنٹ میں درآمد شدہ پروفائل کے پاس ایسا چینل نہیں ہے اور اسے منظور شدہ متبادل درکار ہے۔ موجودہ سیشن کچھ ثابت نہیں کرتے، کیونکہ وہ پرانی قیمت پر قائم کیے گئے تھے۔

جب ویب کنسول لوڈ بیلنسر کے پیچھے ہو، Pritunl سنک راستے کے لیے الگ سنک پتہ ترتیب کی دستاویز کرتا ہے۔ صرف اس لیے کہ دونوں Pritunl ہیں، VPN سننے والے کے لیے کنسول کا ہوسٹ نام دوبارہ استعمال نہ کریں۔

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

تبدیلی کو حقیقی کنکشن سے قبول کریں

حل ہونا سب سے کمزور ممکن آزمائش ہے۔ dig +short vpn.example.net پتہ واپس دے تو یہ صرف ثابت کرتا ہے کہ ریکارڈ موجود ہے۔

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

بعد میں، جب عوامی پتہ ہلے، ریکارڈ اپ ڈیٹ کریں اور کلائنٹ کیشنگ اور دوبارہ جڑنے کے رویے کی منصوبہ بندی کریں۔ ہوسٹ نام کلائنٹ کو عددی پتے سے الگ کرتا ہے؛ یہ زندہ ساکٹ کو نہیں ہلاتا اور نہ ناقابل رسائی سننے والے کو جواب دینے پر مجبور کرتا ہے۔