هاب مجازی 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 هنوز به شبکه محلی اشاره می‌کند، اتصال نیمه‌کاره کلاسیک را پدید می‌آورد.

کاربرد را بیازمایید نه پیوند را. صفحه‌ای از اینترانت که بارگذاری می‌شود شاهد قوی‌تری از آداپتوری با نشانی باورپذیر است.