SoftEther کا مجازی حب دراصل کیا جوڑتا ہے

SoftEther کا مجازی حب ایک سرور کے اندر رکنیت کی حد ہے، کوئی مقام نہیں۔ حب میں شامل ہونے والے سیشن اُس چیز تک پہنچ سکتے ہیں جس سے حب جڑا ہے، اور دوسرے حب کے سیشن نہیں پہنچ سکتے، چاہے دونوں ایک ہی سرور پر توثیق کریں۔ اسی لیے کامیاب لاگ اِن بھی کلائنٹ کو غلط نیٹ ورک پر رکھ سکتا ہے۔ حب کو مجازی سوئچ کے طور پر پڑھنا واضح کرتا ہے کہ یہ کیا کرتا ہے اور کیا بریجنگ، روٹنگ اور کاسکیڈ ترتیب پر چھوڑ دیتا ہے۔

حب رکنیت کی حد ہے

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

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

انتظام بھی اسی طرح محدود ہے۔ حب منتظم اُس حب کا انتظام کرتا ہے، جبکہ سرور منتظم عمل، سامعین اور میزبان پر ہر حب کا انتظام کرتا ہے۔

ربط طے کرتے ہیں کہ پار کیا ہے

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

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

کاسکیڈ دو سرور جوڑتا ہے تاکہ ایک حب کے سیشن دوسرے پر ظاہر ہو سکیں۔ یہ حب سے حب کا رشتہ ہے، اس لیے دونوں سروں کو موافق پالیسی اور اُن کے درمیان کام کرنے والا راستہ چاہیے۔

سیشن اور پالیسی الگ الگ پڑھیں

سیشن، MAC پتوں اور IP پتوں کے منظر بیان کرتے ہیں کہ مجازی نیٹ ورک اب کیسا دکھتا ہے۔ یہ مشاہدے ہیں، اجازتیں نہیں۔ فہرست میں نظر آنے والا سیشن اس وجہ سے ہر اُس سروس کا حقدار نہیں جہاں حب پہنچ سکتا ہے، اور اُلٹا بھی سچ ہے۔

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

سرور پر، vpncmd میزبان کے نقطۂ نظر سے وہی تصویر بتاتا ہے۔ جب دونوں متفق نہ ہوں تو اُس اخراج کا موازنہ کلائنٹ کے اپنے منظر سے کریں۔

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

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

شامل ہونے کے بعد کلائنٹ کی جانچ کریں

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

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

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

لنک نہیں، ایپلیکیشن جانچیں۔ لوڈ ہونے والا انٹرانیٹ صفحہ قابلِ اعتماد پتہ والے اڈاپٹر سے زیادہ مضبوط ثبوت ہے۔