پل محلی SoftEther یا SecureNAT: کدام را روشن کنیم

SoftEther Manager را باز کنید؛ نخستین تصمیم واقعی دربارهٔ یک هاب یک کادر انتخاب نیست، بلکه پرسشی دربارهٔ توپولوژی است. پل محلی آن هاب را به یک آداپتور فیزیکی متصل می‌کند و می‌گذارد بخش موجود نشانی‌دهی را تأمین کند، در حالی که SecureNAT به هاب روتر مجازی، NAT و DHCP خودش را می‌دهد. انتخاب میان این دو تغییر می‌دهد که نشانی‌ها از کجا می‌آیند و کدام دستگاه پاسخ‌گوی آن‌هاست. روشن کردن هر دو و امید به برنده شدن یکی، همان راهی است که یک آزمایشگاه کارآمد به یک رشتهٔ پشتیبانی تبدیل می‌شود.

از همان هابی شروع کنید که واقعاً ویرایش می‌کنید

Manager درختی از سرورها و هاب‌ها را نشان می‌دهد، و پیکربندی هاب پیش‌فرض آسان است در حالی که کلاینت‌ها به هابی با نامی دیگر وصل می‌شوند. روی هاب کلیک کنید، نامش را بخوانید و تأیید کنید که نشست‌های فهرست‌شده در زیر آن همان کلاینت‌هایی هستند که می‌خواهید سرویس بدهید. همین یک بررسی بیشتر سردرگمی‌ای را که بعداً به گردن پروتکل می‌افتند جلوگیری می‌کند.

سپس تصمیم بگیرید کلاینت از سمت دور چه می‌خواهد. رفتار اشتراکی اترنت با broadcast و سرویس‌های 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 می‌گیرند، روتر مجازی برای دروازهٔ پیش‌فرض پاسخ می‌دهد و ترافیکی که باید خارج شود ترجمه می‌شود. هیچ آداپتور فیزیکی دخالت ندارد، و به همین دلیل روی میزبانی با یک کارت شبکه و بدون پیکربندی سوئیچ کار می‌کند.

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

سپس از کلاینت دوباره متصل شوید و بخوانید چه گرفت، چون دید هاب به نشست همان دید کلاینت به شبکهٔ خودش نیست. اتصال دوباره تنها راه مطمئن برای تحمیل یک اجارهٔ تازه است.

دروازه و resolver را روی کلاینت بررسی کنید

احراز هویت موفق به شما می‌گوید که اعتبارنامه‌ها کار می‌کنند و هاب نشست را پذیرفته است. دربارهٔ این‌که کلاینت به جایی می‌رسد یا نه چیزی نمی‌گوید، چون این به نشانی، ماسک، دروازه و سرور DNS که گرفته بستگی دارد. پیش از آنکه دوباره به تنظیم سرور دست بزنید، آن چهار مقدار را روی کلاینت بخوانید.

در Windows جزئیات آداپتور اجاره و resolver را نشان می‌دهد، و جدول مسیرها نشان می‌دهد آیا تونل واقعاً مسیر پیش‌فرض است.

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

در کلاینت Linux همان اطلاعات از فایل‌های نشانی، مسیر و resolver می‌آید. مسیر پیش‌فرض همان مقداری است که تعیین می‌کند ترافیک اصلاً از تونل خارج می‌شود یا نه. اگر دروازه به روتر دفتر اشاره کند در حالی که تونل انتظار دارد ترافیک را حمل کند، توپولوژی در نام پل شده و در عمل شکسته است. نخست منبع نشانی را درست کنید، سپس برنامه را دوباره بیازمایید و تنها پس از آن تغییر حالت دیگر را در نظر بگیرید.