SoftEther SecureNAT: DHCP اور NAT دو الگ فیصلے ہیں

SecureNAT ایک ہی چیک باکس ہے جو دو سروسز چالو کرتا ہے، اور اس کے بارے میں زیادہ تر الجھن یہیں سے آتی ہے۔ ایک مجازی DHCP سرور کلائنٹ کو پتہ، ماسک، گیٹ وے اور اکثر ایک حل کنندہ دیتا ہے۔ ایک مجازی NAT سرور میزبان کے اپنے نیٹ ورک اسٹیک کو استعمال کرتے ہوئے اس گیٹ وے سے آگے پیکٹ بھیجتا ہے۔ دونوں ترتیب میں ساتھ ساتھ رہتے ہیں اور آزادانہ طور پر ناکام ہوتے ہیں: کلائنٹ کے پاس مکمل لیز ہو سکتی ہے اور کوئی کام کرنے والا راستہ نہ ہو، یا کام کرنے والا راستہ ہو مگر ترتیبات غلط حل کنندہ کی طرف اشارہ کریں۔ انہیں دو فیصلوں کے طور پر جانچیں، اور تشخیص مختصر ہو جاتی ہے۔

ایک چیک باکس کے پیچھے دو سروسز

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

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

فیصلہ 1: پتہ کون دیتا ہے

اگر مجازی DHCP چالو ہے تو کلائنٹ کو آپ کے ترتیب دیے گئے پول میں لیز ملنی چاہیے، گیٹ وے کے طور پر مجازی میزبان انٹرفیس اور حل کنندہ کے طور پر آپ کا دیا ہوا۔ کلائنٹ کے اسٹیٹس متن کے بجائے لیز دیکھیں، کیونکہ «منسلک» سرنگ بیان کرتا ہے، پتہ تقسیم نہیں:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

ایک دوسرے پر چڑھنے والے پول بھی یہیں آتے ہیں۔ اگر مجازی DHCP پول میزبان کے LAN ذیلی نیٹ ورک یا کسی دوسرے ہب کے پول سے چڑھ جائے تو کلائنٹ کو ایسا پتہ ملتا ہے جس کا راستہ مبہم ہوتا ہے، اور بعد کا ہر امتحان غیر فیصلہ کن ہوتا ہے۔

فیصلہ 2: مجازی گیٹ وے سے آگے کون بھیجتا ہے

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

میزبان کا اپنا راستہ تیسری چیز ہے

اوپر کا سب کچھ فرض کرتا ہے کہ سرور میزبان منزل تک پہنچ سکتا ہے۔ جس میزبان کے پاس کام کرنے والا اوپری راستہ نہیں، سخت باہر جانے کی پالیسی ہے، یا جس کے پاس وہ پتہ خاندان نہیں، وہ ہب کی ترتیب کتنی ہی درست ہو، دوسرے فیصلے میں ناکام ہوگا۔ میزبان کو الگ سے، سرنگ سے باہر جانچیں، اس کی ناکامی کا الزام SoftEther پر لگانے سے پہلے۔

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

پتہ خاندان اپنی الگ جانچ کے حق دار ہیں۔ کام کرنے والی IPv4 DHCP مثال یہ ثابت نہیں کرتی کہ آپ کے بلڈ میں ہر IPv6 صلاحیت موجود ہے، اس لیے دوہرے اسٹیک کے رویے کا وعدہ کرنے سے پہلے اس ورژن کا دستی پڑھیں جو آپ واقعی چلاتے ہیں۔ دستی کا SecureNAT حصہ موجودہ ریلیز کے لیے مجازی NAT اور DHCP افعال کا احاطہ کرتا ہے۔

ہر فیصلے کو اس کی اپنی جانچ سے تصدیق کریں

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

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

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