چگونه عبور NAT بسته‌های ESP را درون UDP می‌پیچد

دو کارخواه پشت یک روتر با یک دروازهٔ IPsec صحبت می‌کنند و یکی مدام قطع می‌شود در حالی که دیگری پایدار می‌ماند. ESP بومی پروتکل IP شمارهٔ 50 بدون پورت است، پس مترجم چیزی برای تکیه دادن نقشه ندارد وقتی چند کارخواه یک نشانی را شریک می‌شوند. عبور NAT این شکاف را با پیچیدن ESP در UDP روی 4500 می‌بندد و همان سرآیند بیشتر نشانه‌های بعدی را توضیح می‌دهد. همچنین به دستگاهی اشاره می‌کند که باید تغییر کند.

چرا لایهٔ داده به پورت 4500 می‌رود

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

پوشش یک پاکت است، نه تغییر پروتکل: ESP سرآیند، بررسی یکپارچگی و رمزنگاری خود را نگه می‌دارد و UDP تنها پورت‌هایی را فراهم می‌کند که مترجم نیاز دارد. پورت 500 تبادل IKE را حمل می‌کند؛ 4500 دادهٔ کپسوله‌شده پس از تشخیص و اغلب پیام‌های بعدی IKE را نیز حمل می‌کند. هیچ‌یک از این دو پورت جریان را به اتصال TCP تبدیل نمی‌کند، همان فرضی که بیشتر خوانندگان یک ضبط را گمراه می‌کند.

دو مرحله را به ترتیب بررسی کنید

نخست تبادل کنترل را ثابت کنید، سپس مسیر داده را، و آن دو را در یادداشت‌هایتان جدا نگه دارید. ضبطی که ترافیک روی 500 نشان می‌دهد و هرگز روی 4500 نه، معمولاً یعنی مسیر داده فیلتر شده است، پس اصلاح به قاعدهٔ دیوار آتش تعلق دارد نه به کارخواه.

هر دو پورت را با tcpdump -ni any 'udp port 500 or udp port 4500' بپایید و هنگام فعال بودن جلسه، جدول ترجمه را روی روتر بخوانید. آن جدول پورت مبدأیی را نشان می‌دهد که دروازه واقعاً خواهد دید، و ضبط روی لپ‌تاپ به‌عمد ناهمخوان است: لپ‌تاپ 500 را باور دارد در حالی که دروازه 4500 را با پورت مبدأ ترجمه‌شده می‌بیند، و هر دو درست‌اند. همان جریان، پیش و پس از ترجمه:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

نشانه‌هایی که پوشش توضیح می‌دهد، و دو مورد که نمی‌دهد

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

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

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

مالک نقشه را تغییر دهید، سپس دوباره آزمایش کنید

تنظیمات پشتیبانی‌شدهٔ عبور NAT را روی هر دو همتا دنبال کنید نه اینکه پورت را حدس بزنید. ویرایش پورت مبدأ محلی روی یک کارخواه نمی‌تواند سرویس شنونده در انتهای دور را تغییر دهد و معمولاً نقشهٔ ساخته‌شده را می‌شکند. اگر کارخواه پشت دستگاهی است که کنترلش نمی‌کنید، تغییر به مالک آن تعلق دارد.

پس از هر تغییری هر دو بررسی مرحله‌ای را تکرار کنید و تأیید کنید که یک بستهٔ داده رد می‌شود، نه فقط اینکه صفحهٔ وضعیت سبز شده است. چندتایی‌ها، خروجی جدول نقشه و تغییر قاعده را در یک یادداشت نگه دارید تا نفر بعد از تبادل کنترل از نو شروع نکند. یادداشت‌های strongSwan دربارهٔ عبور NAT تنظیمات کپسوله‌سازی و نگهداری را پشت هر دو مرحله پوشش می‌دهد.