NAT روی سرور VPN یا روی روتر؟ هر دو می‌توانند کار کنند
مسیر پیش‌فرض روی کلاینت خروجی نمی‌سازد. ترجمه روی سرور VPN را با بردن استخر به روتر مقایسه کنید و یک مالک انتخاب کنید.
علامت‌گذاری یک اتصال به‌عنوان مسیر پیش‌فرض روی یک لپ‌تاپ همان گامی است که همه به یاد دارند، و همان گامی است که هیچ چیز را روی دروازه تغییر نمی‌دهد. کلاینت اکنون درخواست‌های اینترنت را به داخل تونل می‌فرستد؛ اینکه از ساختمان خارج شوند به ارسال به جلو، یک نقطه ترجمه و یک مسیر بازگشت بستگی دارد که به نشانی خصوصی کلاینت برسد. دو چیدمان می‌توانند هر سه را فراهم کنند، کار را در جاهای متفاوتی می‌گذارند، و هر دو وقتی کسی مسئول جهت پاسخ نباشد به همان شکل خاموش شکست می‌خورند. انتخاب میان آن‌ها پرسشی است درباره اینکه چه کسی باید استخر کلاینت‌ها را ببیند.
افسانه: مسیر کلاینت خروجی می‌سازد
تونل‌سازی اجباری یک سیاست در سمت کلاینت است: تصمیم می‌گیرد که ترافیک به آداپتور VPN برود نه به آداپتور فیزیکی. مستندات مسیریابی VPN مایکروسافت آن رفتار جداسازی و اجبار را توصیف می‌کند، و این سخنی درباره جدول مسیرهای کلاینت است، نه درباره قواعد ارسال به جلوی سرور. از دید کلاینت تونل جایی است که اینترنت در آن زندگی می‌کند؛ از دید دروازه یک بسته از نشانی‌ای رسیده که هیچ‌کس در بالادست هرگز آن را نشنیده است. هیچ‌یک از دو طرف به‌تنهایی بدپیکربندی نشده است، و برای همین است که این خرابی برای کسی که پشت لپ‌تاپ نشسته مثل یک سرور خراب به نظر می‌رسد.
همین ناهمخوانی تمام مسئله‌ای است که بقیه این مقاله حل می‌کند. چیزی باید نشانی خصوصی کلاینت را بازگشت‌پذیر کند، و انتخاب این است که کجا.
اول مسیر پاسخ را رسم کنید
پیش از دست زدن به هر تنظیمی مسیر را با نشانی‌های واقعی بنویسید، و دو نقطه ترجمه نامزد را روی آن علامت بزنید. این آزمایشگاه از یک استخر VPN با نشانی 10.70.0.0/24 با یک کلاینت در 10.70.0.37، نشانی LAN سرور 172.16.40.10، یک روتر در 172.16.40.1 و یک خروجی عمومی 203.0.113.40 استفاده می‌کند.
client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
(translate here?) (or here?)سروری که همین حالا در اینترنت مرور می‌کند فقط مسیر خودش را ثابت می‌کند. بسته‌ای که به‌نام یک کلاینت به جلو فرستاده می‌شود تصمیم دیگری است که سیاست ارسال به جلو روی همان ماشین می‌گیرد، و همان است که معمولاً غایب است. علامت زدن سه نقطه تصمیم روی نمودار گفتگو را هر بار روی یکی از آن‌ها نگه می‌دارد.
گزینه A: ترجمه روی سرور VPN
اینجا سرور مبدأ کلاینت را پیش از سپردن بسته به روتر به نشانی LAN خودش ترجمه می‌کند، و روتر ترجمه معمول خود را در مسیر خروج اعمال می‌کند. در پاسخ، نگاشت روتر نشانی سرور را بازمی‌گرداند و نگاشت سرور نشانی کلاینت را. دو ترجمه حالت‌دار پشت سر هم طبیعی و عملی است، به شرطی که هر دو ثبت شوند؛ روتر هرگز به مسیری به استخر نیاز ندارد، و همین جذابیت این چیدمان است.
Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefixاز این خوانش‌ها استفاده کنید تا ببینید سرور از قبل چه دارد، نه اینکه فرض کنید NAT وجود دارد. قاعده masquerade لینوکس که از یک وبلاگ کپی شده پیکربندی ویندوز نیست، و اجازه در دیوار آتش میزبان برای شنونده VPN همان سیاست اجازه برای فرستادن درخواست کلاینت به جلو نیست. نقش ارسال به جلوی سرور را از سطح مدیریت خودش تأیید کنید، سپس ترجمه را جداگانه ببینید، چون این دو اغلب توسط بخش‌های متفاوتی از یک استقرار فعال می‌شوند.
گزینه B: بردن استخر به روتر
در چیدمان دوم سرور نشانی مبدأ واقعی کلاینت را به جلو می‌فرستد، و روتر آن را ترجمه می‌کند. این استخر کلاینت‌ها را در لبه قابل مشاهده نگه می‌دارد، که اگر روتر جایگاه سیاست ترافیک، ثبت رویداد یا بازرسی باشد کمک می‌کند. همچنین یعنی روتر به یک مسیر بازگشت برای 10.70.0.0/24 نیاز دارد که به 172.16.40.10 اشاره کند، به‌علاوه یک سیاست اینترنت که واقعاً آن پیشوند را در بر بگیرد؛ قاعده‌ای که برای زیرشبکه LAN نوشته شده به‌طور خاموش به استخر گسترش نمی‌یابد.
این را وقتی انتخاب کنید که دستگاه لبه مالک موردنظر سیاست باشد و بتواند پیشوند دیگری را در جدول‌های مسیریابی و ترجمه بپذیرد. ترجمه سمت سرور را وقتی انتخاب کنید که استخر باید در بالادست نامرئی بماند و روتر توسط همان تیم اداره نشود. هیچ‌یک از دو گزینه از هیچ کادر انتخابی روی کلاینت برنمی‌آید، و هیچ‌کدام به‌طور کلی امن‌تر نیست؛ آن‌ها دیدپذیری و نگهداری را در جاهای متفاوتی قرار می‌دهند.
DNS، IPv6 و پذیرش را صریح کنید
ترجمه نشانی حل نام را درست نمی‌کند. کلاینت ممکن است از یک حل‌کننده که با نمایه VPN ارائه می‌شود، یک حل‌کننده خصوصی برای فضای نام مشخص، یا یک حل‌کننده عمومی تأییدشده استفاده کند، و حل‌کننده غیرقابل‌دسترس در آن سیاست پس از کار کردن مسیریابی هم شکست می‌خورد. یک نام و یک نشانی را جداگانه آزمایش کنید تا دو خرابی هرگز در یک گزارش ادغام نشوند.
IPv6 به پاراگراف خودش در طراحی نیاز دارد. ترجمه IPv4 که کار می‌کند هیچ چیزی درباره اینکه کلاینت‌های IPv6 مسیر دارند، منبع عمومی معتبر دارند یا سیاستی که هنگام افتادن تونل آن‌ها را مسدود می‌کند، نمی‌گوید. ناگفته گذاشتن این یعنی نیمی از کلاینت‌ها بی‌صدا دروازه را دور می‌زنند در حالی که نیم دیگر کار می‌کنند.
برای پذیرش، یک درخواست مجاز کلاینت و پاسخش را از هر دو مرز دنبال کنید و بنویسید هر مرز در آن لحظه باید چه نشانی‌ای را ببیند. همین سابقه است که تغییر بعدی استخر را به ویرایشی پنج‌دقیقه‌ای بدل می‌کند، نه بحثی درباره اینکه مسیر بازگشت گمشده مال کیست. سابقه را کنار نمایه کلاینت نگه دارید نه در یک تیکت، چون نمایه همان چیزی است که مهندس بعدی اول پیدا می‌کند.