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

خانواده‌های نشانی بررسی خودشان را می‌خواهند. یک نمونه DHCP کارآمد روی IPv4 ثابت نمی‌کند که هر توانایی IPv6 در ساخت شما وجود دارد، پس پیش از وعده رفتار پشته دوگانه، راهنمای نسخه‌ای را که واقعاً اجرا می‌کنید بخوانید. بخش SecureNAT در راهنما کارکردهای NAT و DHCP مجازی را برای نسخه کنونی پوشش می‌دهد.

هر تصمیم را با آزمون خودش بررسی کنید

تصمیم اول را با بررسی اجاره بپذیرید: نشانی در استخر، درگاه برابر با رابط میزبان مجازی، حل‌کننده همان که پیکربندی کرده‌اید. تصمیم دوم را با درخواستی خروجی از کلاینت به‌همراه نگاهی به جدول NAT روی سرور بپذیرید، زیرا افزایش شمار نشست‌ها تنها شاهد مستقیم این است که ترجمه رخ می‌دهد و نه فقط فعال است.

سپس تفکیک را در یادداشت طراحی ثبت کنید: کدام مؤلفه نشانی را می‌دهد، کدام مؤلفه ارسال می‌کند و ترافیک از کدام رابط میزبان بیرون می‌رود. وقتی راه‌اندازی مجدد رفتاری را تغییر دهد، آن یادداشت می‌گوید کدام یک از این سه را بررسی کنید، به‌جای راه‌اندازی مجدد همه چیز و امید به جابه‌جا شدن نشانه.

یک تصمیم دیگر هم به پرونده تعلق دارد، حتی اگر امروز آن را نگیرید: SecureNAT و یک پل محلی دو طراحی متفاوت برای همان هاب‌اند، و هابی که به هر دو نیاز دارد هابی است که به طرحی دیگر نیاز دارد. آگاهانه انتخاب کنید، دلیلش را بنویسید و نفر بعدی مجبور نخواهد بود آن را از پیکربندی در حال اجرا مهندسی معکوس کند.