کشف NAT به یک پرسش پاسخ می‌دهد: آیا نشانی‌ها یا درگاه‌ها در مسیر تغییر کرده‌اند؟ پاسخ نمی‌دهد که آیا دیوار آتشی پروتکل IP 50 را مجاز می‌داند. دروازه‌های سایت که هیچ ترجمه‌ای ندارند می‌توانند هنوز پشت سیاستی باشند که native ESP را می‌اندازد، و این الزام باید پیکربندی شود نه کشف. سازوکار ESP-in-UDP است و این یک تصمیم است، نه جایگزینی که خودبه‌خود پدید آید.

کشف، حساب روی نشانی‌هاست، نه کاوش دیوار آتش

IKEv2 بارهای کشف NAT را حمل می‌کند که دربردارندهٔ هش نشانی‌ها و درگاه‌های مبدأ و مقصد است. هر طرف آنچه دریافت کرده را با آنچه محلی می‌بیند مقایسه می‌کند و ناسازگاری به آن می‌گوید چیزی بسته را ترجمه کرده است. هیچ‌چیز در آن تبادل نمی‌آزماید که آیا مسیریابی در میانه پروتکل 50 را عبور می‌دهد.

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

پس کپسوله‌سازی ویژگی اتصالی است که پیکربندی می‌کنید، نه نتیجه‌ای که همتایان از رفتار شبکه مذاکره کنند.

چگونه encap تبادل را تغییر می‌دهد

در استقرار مدرن strongSwan که از طریق swanctl.conf مدیریت می‌شود، تنظیم encap = yes روی اتصال بر تبادل کشف NAT اثر می‌گذارد تا هر دو همتا برای ESP از کپسوله‌سازی UDP استفاده کنند. بسته‌های محافظت‌شده سپس درون UDP، معمولاً روی درگاه 4500، سفر می‌کنند و هر دو نقطهٔ پایانی باید بر این ترتیب توافق کنند.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

راهنمای strongSwan دربارهٔ NAT-traversal این رفتار را توصیف می‌کند، از جمله تعامل با شناوری درگاه هنگام استفاده از MOBIKE.

از تنظیمی استفاده کنید که به بک‌اند شما تعلق دارد

strongSwan دو بک‌اند پیکربندی دارد و کلید میان آن‌ها متفاوت است. swanctl.conf اتصال encap می‌گیرد، در حالی که ipsec.conf اتصال قدیمی forceencaps را می‌گیرد. گذاشتن کلیدواژهٔ یک بک‌اند در دیگری پیکربندی‌ای می‌سازد که بدون گلایه بارگذاری می‌شود و هیچ چیز را تغییر نمی‌دهد، که از خطا بدتر است.

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

تغییر را از طریق مالک اتصال اعمال کنید و انجمن را در پنجره‌ای کنترل‌شده دوباره برقرار کنید. childای که از پیش نصب شده کپسوله‌سازی کنونی‌اش را تا جایگزینی نگه می‌دارد، پس ویرایش فایل به‌تنهایی اثبات نمی‌کند که ترتیب جدید در حال استفاده است.

داده‌های پیچیده‌شده را بررسی کنید، نه فقط درگاه را

هنگام جریان ترافیک محافظت‌شده روی دروازه ثبت کنید و سپس آن را با دید خود strongSwan مقایسه کنید:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP به‌صورت پروتکل IP 50 ظاهر می‌شود و هیچ شبیه UDP نیست. ESP پیچیده‌شده به‌صورت داده‌گرام‌های UDP روی 4500 ظاهر می‌شود که بار آن‌ها IKE نیست. ترافیک IKE روی همان درگاه اثبات کپسوله‌سازی نیست، چون MOBIKE می‌تواند IKE را به آنجا ببرد در حالی که مسیر داده native می‌ماند، پس بار را بخوانید نه شمارهٔ درگاه را.

MTU مسیر را هم در نظر داشته باشید. پوشش سرباری می‌افزاید و مسیری که native ESP را حمل می‌کرد ممکن است با بزرگ‌شدن بسته‌ها به تنظیم نیاز پیدا کند. پردازش ICMP لازم باید از پیش بخشی از طراحی باشد؛ کپسوله‌سازی آن وابستگی را برنمی‌دارد.

تغییر را بپذیرید وقتی ترافیک تازهٔ برنامه‌ها درون تونل در ثبت به‌صورت ESP پیچیده‌شده در دو سر دیده شود، و وقتی سرویس درونی و مسیر بازگشتش هنوز کار کنند. هر چیزی کمتر، پیکربندی‌ای است که در فایل درست به نظر می‌رسد.

مقالات مرتبط