SoftEther کا مقامی پل یا SecureNAT: کسے فعال کریں

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

اسی ہب سے شروع کریں جسے آپ واقعی ترمیم کر رہے ہیں

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

پھر طے کریں کہ کلائنٹ کو دور والے سرے سے کیا درکار ہے۔ نشریات اور LAN خدمات کے ساتھ مشترکہ ایتھرنیٹ رویہ پل کی طرف اشارہ کرتا ہے، چھوٹی پتہ رینج تک راوٹ شدہ نجی رسائی SecureNAT کی طرف، اور انٹرنیٹ سے اخراج ایک راوٹنگ فیصلہ ہے جسے دونوں ترتیبیں بری طرح اٹھا سکتی ہیں۔

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

مقامی پل پتوں کے ساتھ کیا کرتا ہے

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

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

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

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

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

SecureNAT کیا شامل کرتا ہے اور کیا چھپاتا ہے

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

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

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

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

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

ایک کو فعال کرنا، دوسرے کو توڑے بغیر

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

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

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

کلائنٹ پر گیٹ وے اور حل کنندہ جانچیں

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

Windows پر اڈاپٹر کی تفصیل لیز اور حل کنندہ دکھاتی ہے، اور راوٹ جدول دکھاتا ہے کہ ٹنل واقعی طے شدہ راستہ ہے یا نہیں۔

ipconfig /all
route print -4
nslookup intranet.corp.internal

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