مجموعه پروتکل‌های IPsec تبادل داده‌ها را در لایه سوم شبکه بر روی بسترهای عمومی ایمن می‌سازد. در دوره‌ای که این معماری توسعه یافت، فرض بر این بود که تمامی میزبان‌های شبکه دارای نشانی‌های سراسری و قابل مسیریابی در IPv4 هستند. پروتکل Encapsulating Security Payload (ESP با کد پروتکل 50) وظیفه برقراری محرمانگی، احراز هویت مبدأ و پیشگیری از بازپخش بسته‌ها را بر عهده دارد. با اتمام نشانی‌های IPv4 و رواج فراگیر فناوری‌های ترجمه نشانی و پورت شبکه (NAT/PAT)، ناسازگاری فنی پدیدار شد: پروتکل ESP خام مستقیماً روی لایه IP مستقر است و هیچ پورتی در لایه انتقال (TCP/UDP) ندارد. در نتیجه، درگاه‌های میانی توانایی ردیابی یا تفکیک جریان‌های رمزشده برگشتی را از دست می‌دهند. استانداردهای RFC 3947 و RFC 3948 این گره ساختاری را با قرار دادن بسته‌های ESP درون دیتاگرام‌های پروتکل UDP روی درگاه 4500 برطرف کرده‌اند.

معماری ESP خام (عدم سازگاری با درگاه‌های PAT/NAT):
[سربرگ IP (Proto 50)] [سربرگ ESP: کد SPI (۴ بایت), دنباله (۴ بایت)] [داده‌های رمزشده]
                    └──> فاقد درگاه UDP/TCP! دستگاه PAT ترافیک بازگشتی را هدایت نمی‌کند.

کپسوله‌سازی ESP طبق استاندارد RFC 3948 (روی پورت UDP 4500):
[سربرگ IP (Proto 17)] [سربرگ UDP (مبدأ 4500, مقصد 4500)] [ESP] [داده‌های رمزشده]
                    └──> پورت‌های لایه ۴ پایش وضعیت نشست‌ها را در NAT ممکن می‌سازند.

چالش ترجمه پورت PAT: چرایی ناسازگاری پروتکل خام ESP با سامانه‌های NAT

درک چرایی ضرورت استفاده از مکانیزم IPsec NAT-Traversal نیازمند بررسی شیوه مدیریت سربرگ‌ها در تجهیزات وضعیت‌مند ترجمه آدرس است.

نبود درگاه در لایه انتقال: فقدان پورت‌های TCP/UDP در بسته ESP

هنگامی که چندین دستگاه درون یک شبکه اداری یا پشت تجهیزات دروازه اپراتوری CGNAT همزمان با سرورهای خارجی ارتباط برقرار می‌کنند، روتر نشانی‌های خصوصی آن‌ها را به یک نشانی عمومی اشتراکی تبدیل می‌نماید. برای تشخیص این‌که بسته پاسخ ورودی به کدام میزبان داخلی تعلق دارد، درگاه ترجمه یک شماره درگاه مبدأ یکتا در لایه انتقال به هر نشست خروجی TCP یا UDP اختصاص می‌دهد.

پروتکل ESP در لایه ۳ و ذیل شناسه پروتکل 50 کار می‌کند. بر خلاف پروتکل‌های TCP یا UDP، بسته ESP هیچ سربرگی برای شماره پورت ندارد. نخستین ۴ بایت سربرگ ESP شامل شاخص پارامتر امنیتی (Security Parameter Index یا SPI) است؛ مقداری ۳۲ بیتی که گیرنده برای شناسایی بستره امنیتی (SA) تعیین می‌کند:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data (Variable)                    |

هنگامی که یک بسته ESP از دروازه PAT عبور می‌کند، دستگاه نشانی مبدأ را تغییر می‌دهد، ولی توانایی تخصیص نگاشت پورت را ندارد. زمانی که پاسخ دریافت می‌شود، تجهیزات NAT سربرگ را بررسی می‌کنند و چون هیچ درگاه مقصدی وجود ندارد، نمی‌توانند مقصد داخلی بسته را تعیین کنند. هرچند برخی مسیریاب‌ها از رویکرد آزمایشی گذرگاه SPI پشتیبانی می‌کنند، این روش زمانی که چند کلاینت همزمان به یک سرور متصل شوند کارایی ندارد.

دگرگونی مسیر شبکه و ابطال مجموع مقابله‌ای TCP/UDP

مشکل دومی در حالت انتقال (Transport Mode) بروز می‌یابد. الگوریتم‌های درستی‌سنجی مجموع مقابله‌ای در شبه‌سربرگ‌های TCP و UDP، درستی نشانی‌های مبدأ، مقصد، پروتکل و طول داده را محاسبه می‌نمایند. با تغییر نشانی IP در دروازه میانی، مجموع مقابله‌ای که توسط فرستنده محاسبه شده باطل می‌شود. چون بدنه اصلی بسته توسط ESP کاملاً رمزنگاری شده است، تجهیزات میانی قادر به محاسبه دوباره مجموع مقابله‌ای نیستند. هنگام رمزگشایی در مقصد، ارزیابی خطا رد شده و هسته سیستم‌عامل بسته را بی‌صدا دور می‌اندازد.

سازوکار شناسایی RFC 3947 NAT-Discovery: تشخیص پویای گذرگاه‌های میانی

برای حل پویای این چالش، استاندارد RFC 3947 (که در IKEv2 RFC 7296 ادغام شده) فرایند خودکار کشف ترجمه آدرس (NAT-Discovery یا NAT-D) را در نخستین گام‌های ایجاد بستره امنیتی تعریف می‌کند.

داده‌های بارگذاری NAT-D و مقایسه درهم‌سازی در مرحله IKE_SA_INIT

در تبادل اولیه (IKE_SA_INIT)، کلاینت و سرور روی درگاه استاندارد UDP 500 با یکدیگر مذاکره می‌کنند. طرفین بارگذاری‌های موسوم به NAT-D را مبادله می‌نمایند که دربردارنده حاصل درهم‌سازی رمزنگارانه نشانی IP و پورت فرستنده و گیرنده است:

$$\text{NAT-D Hash} = \text{SHA-1}(\text{SPI}_i ,|, \text{SPI}_r ,|, \text{IP} ,|, \text{Port})$$

۱. فرستنده مقدار درهم‌سازی نشانی محلی و نشانی مقصد را محاسبه نموده و ارسال می‌دارد. ۲. گیرنده نیز با دریافت بسته، حاصل درهم‌سازی نشانی‌های مشاهده‌شده واقعی را محاسبه می‌کند. ۳. در صورتی که مقادیر ارسالی با مقادیر دریافتی همخوانی داشته باشند، هیچ‌گونه ترجمه نشانی در طول مسیر وجود ندارد. ۴. بروز هرگونه ناهمخوانی میان مقادیر، نشانه وجود یک سامانه NAT در میانه راه است که نشانی را بازنویسی نموده است.

شناورسازی پورت: گذار پیوسته از UDP 500 به UDP 4500

به محض این‌که فرایند NAT-D وجود ترجمه نشانی را اثبات کند، طرفین شناورسازی پورت (Port Floating) را فعال می‌نمایند. از بسته بعدی (IKE_AUTH)، مسیر تبادلات از UDP 500 به سمت UDP 4500 هدایت می‌شود.

جابجایی به درگاه 4500 اختلالات ناشی از انسداد UDP 500 توسط برخی فایروال‌ها را از میان برمی‌دارد و بستر را برای انتقال همزمان بسته‌های داده و پیام‌های مدیریتی آماده می‌سازد.

معماری کپسوله‌سازی RFC 3948: جایگاه نشانگر ۴ بایتی Non-ESP

چالش اصلی در استفاده از پورت مشترک UDP 4500، ضرورت دریافت همزمان داده‌های مدیریتی IKE و بسته‌های رمزشده کاربردی ESP است. استاندارد RFC 3948 این مسئله را با ابتکاری هوشمندانه مدیریت می‌کند.

تفکیک ترافیک کنترلی IKE از داده‌های رمزشده ESP

با ورود دیتاگرام به درگاه UDP 4500، پشته شبکه IPsec باید بلافاصله مشخص کند که بسته ورودی پیامی کنترلی است (که باید به پردازه مدیریتی کاربر تحویل داده شود) یا بسته‌ای رمزشده است (که باید فوراً به شتاب‌دهنده رمزنگاری هسته فرستاده شود).

این دسته‌بندی با بررسی نشانگر Non-ESP Marker با طول ۴ بایت انجام می‌شود:

بسته کنترلی IKE روی پورت 4500 (دارای نشانگر Non-ESP):
+---------------------------------------------------------------+
| سربرگ UDP (پورت مبدأ: نامشخص، پورت مقصد: 4500)                 |
+---------------------------------------------------------------+
| نشانگر Non-ESP Marker: مقدار 0x00000000 (چهار بایت صفر)       |
+---------------------------------------------------------------+
| سربرگ پیام IKEv2 (شناسه‌های تبادل و پرچم‌های رمزنگاری)         |
+---------------------------------------------------------------+

بسته رمزشده ESP روی پورت 4500 (بدون نشانگر صفر):
+---------------------------------------------------------------+
| سربرگ UDP (پورت مبدأ: نامشخص، پورت مقصد: 4500)                 |
+---------------------------------------------------------------+
| شناسه ESP SPI (۳۲ بیت، مقداری قطعاً غیرصفر: 0xXXXXXXXX)       |
+---------------------------------------------------------------+
| شماره توالی بسته ESP (۳۲ بیت)                                 |
+---------------------------------------------------------------+
| داده‌های رمزشده و کدهای درستی‌سنجی ICV                         |
+---------------------------------------------------------------+

بر اساس استاندارد RFC 4303، چهار بایت ابتدایی یک بسته ESP به مقدار SPI اختصاص دارد و مقدار 0x00000000 در این پروتکل غیرمجاز است و هرگز به یک بستره معتبر تخصیص نمی‌یابد. در نتیجه اگر ۴ بایت پس از سربرگ UDP صفر باشد، هسته سیستم آن را به عنوان پیام IKE تشخیص داده و به برنامه کنترل تحویل می‌دهد؛ اما اگر این فیلد مقداری غیرصفر داشته باشد، به عنوان SPI بسته ESP تلقی شده و مستقیماً در هسته رمزگشایی می‌شود.

سازوکار زنده نگه‌داشتن NAT Keepalive و زمان‌سنج‌های جدول ترجمه وضعیت

درگاه‌های NAT وضعیت نشست‌های UDP را در جداول موقت ذخیره می‌کنند. چنانچه در طول یک نشست تبادلی صورت نگیرد، روتر مدخل جدول را پس از سپری شدن مهلت مقرر (معمولاً میان ۳۰ تا ۱۲۰ ثانیه در شبکه‌های تلفن همراه) پاک می‌کند و پس از آن بسته‌های ورودی به کلاینت نخواهند رسید.

برای مقابله با این مشکل، استاندارد RFC 3948 ارسال متناوب بسته‌های نگه‌دارنده (Keepalive) را تعریف نموده است. کلاینت هر چند ثانیه یک‌بار بسته‌ای تک‌بایتی ارسال می‌کند:

+-----------------------------------------------+
| سربرگ IP (کد پروتکل 17، نشانی‌های ارتباطی)    |
+-----------------------------------------------+
| سربرگ UDP (مبدأ 4500، مقصد 4500، طول ۹ بایت)  |
+-----------------------------------------------+
| مقدار 0xFF (بایت منفرد نگه‌دارنده ارتباط)     |
+-----------------------------------------------+

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

سربرگ سربار تونل، کاوش بیشینه اندازه بسته Path MTU و مهار TCP MSS

کپسوله‌سازی بسته‌ها در پروتکل UDP موجب افزایش طول سربرگ‌ها شده و ضرورت تنظیم دقیق متغیرهای MTU را پررنگ می‌سازد.

افزوده شدن سربرگ ۸ بایتی UDP ظرفیت موثر بسته‌های عبوری را می‌کاهد. در یک پیوند استاندارد اترنت با اندازه 1500 بایت:

  • سربار پروتکل استاندارد IPv4 ESP با الگوریتم‌های رایج رمزنگاری بین ۵۰ تا ۶۰ بایت است.
  • لایه کپسوله‌سازی UDP مقدار ۸ بایت دیگر می‌افزاید و مجموع سربار را به ۶۲ الی ۷۲ بایت می‌رساند.
  • پارامتر بیشینه اندازه قطعه (TCP MSS) باید از مقدار معمول ۱۴۶۰ به حدود ۱۳۶۰ تا ۱۳۸۰ بایت کاهش یابد (MSS Clamping).

در غیاب این تنظیمات، بسته‌های بزرگ شبکه دچار شکستگی و تکه‌تکه شدن (Fragmentation) می‌گردند. از آنجا که روترهای بسیاری از ارائه‌دهندگان اینترنت بسته‌های تکه‌تکه‌شده را حذف می‌کنند، نادیده گرفتن این پارامتر موجب کندی شدید یا قفل شدن نشست‌های انتقال داده خواهد شد.

پایداری در شبکه‌های سازمانی CGNAT: پیاده‌سازی با فناوری RiceGuard

سامانه امنیتی RiceGuard در ساختار VPNRice استانداردهای RFC 3948 و RFC 3947 را برای فراهم‌سازی اتصالات بی‌وقفه در شبکه‌های پیچیده مخابراتی به کار می‌گیرد.

معماری تونل‌های مبتنی بر اعتماد صفر در RiceGuard:
کلاینت سیار / پایانه کاربر
  │  (پشت درگاه CGNAT یا سامانه‌های NAT دوگانه)
  │  آغاز تبادل IKE_SA_INIT روی پورت UDP 500
  ▼
آزمون خودکار شاخص‌های NAT-D
  │  - تشخیص دگرگونی نشانی خارجی در مسیر
  │  - هدایت بلادرنگ نشست به پورت UDP 4500
  │  - الحاق نشانگرهای ۴ بایتی Non-ESP به پیام‌ها
  ▼
درگاه پرظرفیت RiceGuard
  │  - پردازش ترافیک ESP کپسوله‌شده در UDP 4500
  │  - مدیریت شتاب‌یافته جداول SAD از طریق XFRM
  │  - تنظیم هوشمندانه بازه‌های ارسال Keepalive
  ▼
شبکه امن سازمانی / اتصال پایدار به اینترنت

۱. جابجایی قطعی و هوشمند پورت: سیستم RiceGuard بی‌درنگ وضعیت ترجمه نشانی را شناسایی کرده و پورت ارتباطی را به ۴۵۰۰ منتقل می‌سازد تا از مسدودسازی پورت ۵۰۰ توسط ارائه‌دهندگان اینترنت در امان بماند. ۲. زمان‌بندی انطباقی بسته‌های نگه‌دارنده: این سازوکار نرخ ارسال بسته‌ها را بر پایه مشخصات شبکه مقصد تنظیم می‌کند تا ضمن حفظ اتصال، در مصرف باتری دستگاه‌ها صرفه‌جویی شود. ۳. تفکیک پرسرعت ترافیک در هسته لینوکس: با بکارگیری مستقیم ساختار سوکت‌های XFRM در سطح هسته، بسته‌های داده مستقیم وارد پردازنده‌های سخت‌افزاری رمزنگاری می‌شوند و سرریز پردازشی به حداقل می‌رسد.

آزمون و عیب‌یابی سامانه: بررسی سوکت‌های NAT-T و پایگاه داده SAD هسته لینوکس

مدیران شبکه می‌توانند با ابزارهای بومی لینوکس وضعیت بسترهای NAT-T را پایش نمایند.

بررسی وضعیت شنود سوکت‌های UDP 4500

اطمینان از فعال بودن شنود پورت‌های ارتباطی ۵۰۰ و ۴۵۰۰ توسط سرویس IPsec:

# پایش پورت‌های باز UDP مرتبط با پروتکل‌های IKE و NAT-T
ss -uan '( sport = :500 or sport = :4500 )'

نمونه خروجی استاندارد:

State    Recv-Q    Send-Q       Local Address:Port        Peer Address:Port
UNCONN   0         0                  0.0.0.0:500              0.0.0.0:*
UNCONN   0         0                  0.0.0.0:4500             0.0.0.0:*

پایش وضعیت پایگاه امنیتی XFRM برای پارامترهای کپسوله‌سازی UDP

بررسی پایگاه پیوندهای امنیتی (SAD) در هسته لینوکس برای راستی‌آزمایی تنظیمات کپسوله‌سازی:

# نمایش پیوندهای فعال IPsec به همراه جزییات کپسوله‌سازی
ip xfrm state show

بخش خروجی مربوطه:

src 198.51.100.2 dst 203.0.113.1
	proto esp spi 0xc7a41289 reqid 1 mode tunnel
	replay-window 64 flag af-unspec
	auth-trunc hmac(sha256) 0x6e7a... 128
	enc cbc(aes) 0x4f12...
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	sel src 0.0.0.0/0 dst 0.0.0.0/0

عبارت encap type espinudp نشان‌دهنده این است که هسته لینوکس داده‌های خروجی را با سربرگ UDP 4500 بسته‌بندی کرده و بسته‌های ورودی را نیز در همین ساختار پردازش می‌کند.

استاندارد RFC 3948 نقطه عطفی در تداوم کارایی پروتکل‌های امنیتی IPsec در بستر شبکه‌های دارای NAT به شمار می‌رود. بسته‌بندی داده‌های ESP درون چارچوب‌های استاندارد UDP 4500 و استفاده از نشانگرهای دقیق Non-ESP، دسترسی به اتصالات ایمن و با کارایی بالا را در بسترهای سازمانی و مخابراتی تضمین می‌نماید.

برای برپایی تونل‌های پایدار مبتنی بر اعتماد صفر و عبور هموار از دروازه‌های شبکه سازمانی، دریافت VPNRice.