L2TP/IPsec از طریق NAT: واقعاً چه چیزی می‌شکند و چرا

این ادعا که NAT باعث شکستن L2TP/IPsec می‌شود نیمه‌درست و بنابراین بی‌فایده است. ترجمه نشانی عادی است، عبور NAT دقیقاً برای زنده ماندن از آن وجود دارد و میلیون‌ها کلاینت هر روز از پشت یک روتر متصل می‌شوند. آنچه می‌شکند یک مرحله مشخص از یک تبادل مشخص است: IKE هرگز پاسخ نمی‌گیرد، تونل کپسوله‌شده توسط سیاستی که فقط یک پروتکل را مجاز می‌داند دور ریخته می‌شود، یا نگاشت ترجمه در حالی که تونل بی‌کار است منقضی می‌شود. وقتی بدانید در کدام مرحله هستید، راه‌حل معمولاً یک قاعده یا یک keepalive است، نه طراحی تازه VPN.

افسانه، پرسش نادرست است

پرسش سودمند این نیست که «آیا NAT این را می‌شکند» بلکه «کدام بخش تبادل ترجمه می‌شود و دستگاه مترجم با آن چه می‌کند». L2TP/IPsec یک پروتکل لایه‌ای است: IKE مذاکره می‌کند، ESP محافظت می‌کند و L2TP درون آن محافظت PPP را حمل می‌کند. ترجمه نشانی با هر لایه متفاوت تعامل می‌کند و امضای شکست‌ها را می‌توان تشخیص داد اگر به مرحله مذاکره نگاه کنید نه به پنجره خطا.

روتری که با موفقیت وبگردی می‌کند فقط ثابت می‌کند TCP با ترجمه پورت مبدأ کار می‌کند. درباره UDP 500 یا UDP 4500 یا پروتکل 50 چیزی نمی‌گوید و این استقرار دقیقاً به همین سه چیز وابسته است.

مرحله 1: IKE باید اصلاً پاسخی بگیرد

نخستین تبادل روی UDP 500 به پاسخ‌دهنده می‌رود. اگر پاسخی برنگردد، هیچ چیز دیگری مهم نیست: کلید از پیش مشترک، پیشنهاد و اعتبارنامه‌ها خوانده‌نشده می‌مانند. به‌جای استنتاج از مهلت کلاینت، درخواست و پاسخ را زیر نظر بگیرید:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

مرحله 2: کپسوله‌سازی آنچه فایروال می‌بیند را تغییر می‌دهد

ESP یک پروتکل IP است نه پورت TCP یا UDP، و ترجمه نشانی پورت معمولی هیچ فیلد پورتی برای بازنویسی ندارد. به همین دلیل عبور NAT بار محافظت‌شده را به UDP 4500 منتقل می‌کند: کپسوله‌سازی به دستگاه مترجم چیزی می‌دهد که می‌داند چگونه ترجمه کند. پس از آن، قاعده فایروالی که فقط برای UDP 500 نوشته شده مذاکره را مجاز می‌داند و تونل را دور می‌ریزد، که نتیجه گیج‌کننده‌ای می‌دهد: گزارش فاز 1 موفق را نشان می‌دهد و هیچ ترافیکی نیست.

خود تبادل IKE هم می‌تواند پس از تشخیص NAT به UDP 4500 منتقل شود، که کسانی را که فقط 500 را مجاز کرده‌اند غافلگیر می‌کند. هر دو پورت را در هر دو جهت روی مسیر مجاز کنید و به یاد داشته باشید فایروال حالتمند فقط تا زمانی جریان را نگه می‌دارد که ترافیک ببیند.

پروتکل 50 هنوز روی مسیرهای بدون ترجمه مهم است و روی مسیرهایی که جعبه میانی برای مجاز کردن آن پیکربندی شده است. اگر با حذف تشخیص می‌دهید، فرضیه را خاموش کنید نه اینکه قاعده‌ها را دسته‌ای اضافه کنید: 500 و 4500 و ESP را مجاز کنید، تأیید کنید تونل بالا می‌آید، سپس آنچه غیرضروری بود را بردارید. قاعده‌ای که هیچ‌کس نمی‌تواند توضیح دهد، قاعده‌ای است که هیچ‌کس هنگام تبدیل شدن به علت قطعی بعدی حذفش نمی‌کند. محدودسازی را همراه با مرحله‌ای که اصلاح کرد در سابقه تغییرات بنویسید تا مهندس بعدی از شواهد شما شروع کند نه از همان قاعده سرانگشتی.

مرحله 3: نگاشت منقضی می‌شود و تونل می‌میرد

دستگاه مترجم برای جریان‌هایی که ارسال می‌کند حالت نگه می‌دارد و آن حالت عمر دارد. تونل L2TP/IPsec وقتی کسی از آن استفاده نمی‌کند ترافیک کمی حمل می‌کند، بنابراین تونل بی‌کار می‌تواند از نگاشتش بیشتر عمر کند و دریافت ترافیک بازگشتی را متوقف کند. کلاینت مطمئن می‌ماند که متصل است، سرور چیزی نمی‌بیند و نخستین نشانه معمولاً مهلت یک برنامه است نه خطای VPN.

تشخیص همتای مرده و keepaliveهای NAT برای همین وجود دارند و هر دو سو باید حاضر به فرستادنشان باشند. اگر سرور شما پشت ترجمه است، شرط سمت Windows یک تنظیم رجیستری مستند است که سرور را وادار می‌کند برای بسته‌های خروجی خود کپسوله‌سازی UDP را فرض کند؛ بدون آن پاسخ‌دهنده ESP می‌فرستد که دستگاه مترجم نمی‌تواند بازگردانی کند. این مسئله پیکربندی سرور است نه کلاینت.

تغییر نشانی WAN همان نتیجه را از جهت دیگر می‌دهد: نگاشت حول نشانی جدید بازسازی می‌شود و انجمن امنیتی قدیمی اکنون به چندتایی اشاره می‌کند که دیگر وجود ندارد. رفتار اتصال مجدد به پیاده‌سازی کلاینت مربوط است و به همین دلیل «پس از راه‌اندازی مجدد روتر دوباره وصل شو» روی یک کلاینت کار می‌کند و روی دیگری به کلید دستی نیاز دارد.

میزبانی پشت NAT اپراتوری مسئله‌ای دیگر است

اگر می‌خواهید سرور L2TP/IPsec را در خانه میزبانی کنید و از بیرون به آن برسید، شرط دسترسی‌پذیری ورودیِ درخواست‌نشده است و عبور NAT این را فراهم نمی‌کند. NAT اپراتوری جلوی روتر شما یعنی هیچ پورتی نیست که با هدایتش شما را دسترس‌پذیر کند، چون نشانی عمومی مشترک است و نگاشت فقط خروجی است.

هیچ تیک IPsec pass-through این را تغییر نمی‌دهد و هیچ مقدار پیکربندی کلاینت آن را جبران نمی‌کند. پاسخ‌های پشتیبانی‌شده عبارت‌اند از نشانی‌ای که واقعاً دسترس‌پذیر است، نقطه پایانی میزبانی‌شده، یا معماری‌ای که هر مشارکت‌کننده اتصال خروجی برقرار می‌کند. مشخصات کپسوله‌سازی UDP مشکل ترجمه را برای جریان‌های موجود حل می‌کند؛ مسیر ورودی‌ای که اپراتور ارائه نمی‌دهد را ایجاد نمی‌کند.

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