در دوران اولیه اینترنت، برقراری اتصال مستقیم میان دو رایانه با ارسال مستقیم بسته ها به یک نشانی IP عمومی به سادگی انجام می گرفت. با این حال، در بستر امروزی پروتکل IPv4، امکان برقراری ارتباط دوطرفه سرتاسری تقریبا از میان رفته است. رواج گسترده فناوری ترجمه نشانی شبکه (NAT)، سامانه های اپراتوری موسوم به Carrier-Grade NAT (استاندارد RFC 6598) و دیواره های آتش وضعیت دار سبب شده تا دستگاه های کاربران، تلفن های همراه و سرورها در لایه های متعدد شبکه های محلی و بدون نشانی IP عمومی پایدار مستقر شوند.

هنگامی که دو رایانه در پشت دو دروازه NAT جداگانه قصد دارند یک کانال ارتباطی رمزگذاری شده مستقیم برای انتقال فایل همتا به همتا (P2P)، تماس های صوتی یا اتصال شبکه های تور مانند VPN ایجاد کنند، نمی توانند صرفا یک درگاه را باز کرده و منتظر بمانند. هر بسته ورودی که از سوی اینترنت بدون پیشینه اتصال قبلی برسد، توسط دیواره آتش میانی بی درنگ حذف می شود.

برای غلبه بر این ساختار مانع، روش های پیمایش NAT (موسوم به NAT Traversal) توسعه یافتند که با تلفیق کشف نشانی های عمومی، تکنیک سوراخ کردن درگاه UDP (یا UDP hole punching) و استفاده از سرورهای رله پشتیبان طبق پروتکل های STUN (استاندارد RFC 8489)، TURN (استاندارد RFC 8656) و ICE (استاندارد RFC 8445) اتصال پایدار را برقرار می سازند.

+--------------------------------------------------------------------------+
|                  ساختار پیمایش NAT و سوراخ کردن کانال UDP                |
|                                                                          |
|  [ گره A ]                                                    [ گره B ]  |
|  192.168.1.50                                                 10.0.0.85  |
|      |                                                            |      |
|      v                                                            v      |
| [ دروازه NAT A ]                                          [ دروازه NAT B]|
| IP بیرونی: 203.0.113.10                                   IP بیرونی: 198 |
|      |                                                            |      |
|      |  بسته ورودی بدون پیشینه (حذف شد: هیچ رکوردی در جدول نیست)  |      |
|      +------------------------- X <-------------------------------+      |
|                                                                          |
|      |            تبادل پیام های هماهنگی به سمت خارج              |      |
|      +----------> [ سرور عمومی هماهنگی و کشف STUN ] <-------------+      |
|                                                                          |
|      |                 ارسال همزمان دوطرفه بسته ها                |      |
|      +=========================> [ مستقیم ] <=====================+      |
|                        تونل داده UDP با موفقیت باز شد                    |
+--------------------------------------------------------------------------+

گونه های چهارگانه NAT و شیوه پالایش ترافیک ورودی

برای پی بردن به چرایی ناکامی اتصال های مستقیم، باید شیوه نگاشت نشانی داخلی به نقطه عمومی توسط دروازه ها را تحلیل کرد (RFC 4787):

1. مدل تمام مخروطی (Full Cone NAT)

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

2. مخروطی با محدودیت نشانی (Restricted Cone NAT)

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

3. مخروطی با محدودیت نشانی و درگاه (Port-Restricted Cone NAT)

این پیکربندی افزون بر نشانی IP، برابری کامل درگاه فرستنده خارجی را نیز الزامی می داند. اگر گره A به یک درگاه مشخص در نشانی مقابل پیامی فرستاده باشد، دروازه فقط و فقط پاسخ های ارسالی از همان درگاه را می پذیرد و ترافیک آمده از درگاه های دیگر دور ریخته می شود.

4. مدل متقارن (Symmetric NAT)

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

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

مجموعه استانداردهای پیمایش: STUN و TURN و ICE

شبکه های مدرن برای حل مشکل عدم دسترسی مستقیم از سه پروتکل مکمل بهره می گیرند:

+-------------------------------------------------------------------------+
|                    مراحل جمع آوری نقاط اتصال در پروتکل ICE              |
|                                                                         |
|  [ رابط محلی دستگاه ] ------> نامزد محلی (Host): 192.168.1.50:51820     |
|                                                                         |
|  [ پرسش از STUN ] ----------> نامزد بازتابی (srflx): 203.0.113.10:45000 |
|                               (کشف شده با صفت XOR-MAPPED-ADDRESS)       |
|                                                                         |
|  [ تقاضا از TURN ] ---------> نامزد رله (Relay): 198.51.100.1:60000     |
|                               (مسیر سرور واسط تضمین شده)                |
|                                                                         |
|  تبادل نامزدها از کانال پیام رسان -> ارزیابی و اولویت بندی مسیرها       |
|  اجرای همزمان آزمون های STUN -> برگزیدن مسیر مستقیم و آغاز ارسال داده   |
+-------------------------------------------------------------------------+

1. پروتکل STUN: ابزار کشف وضعیت NAT (استاندارد RFC 8489)

این پروتکل به عنوان یک سامانه سبک پرسش و پاسخ عمل می کند. دستگاه پنهان در شبکه محلی، پیامی برای درخواست اتصال به سوی سرور عمومی STUN ارسال می کند.

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

2. پروتکل TURN: انتقال داده ها از طریق سرور رله (استاندارد RFC 8656)

هنگامی که هر دو سوی اتصال در پشت دروازه های متقارن یا سامانه های فیلترینگ شرکتی سخت گیرانه قرار دارند، ایجاد مستقیم مسیر ارتباطی ناممکن می گردد. در این وضعیت، سرور TURN به عنوان یک پشتیبان ورود می کند.

دستگاه به سرور TURN متصل شده و تقاضای یک نقطه واسط می کند. گره مقابل تمامی بسته های خود را به نشانی این سرور می فرستد و سرور بسته ها را به مقصد نهایی بازپخش می کند. این شیوه اتصال مطمئن را فراهم می سازد اما موجب مصرف پهنای باند و افزایش تاخیر می شود.

3. پروتکل ICE: برقراری اتصال تعاملی هوشمند (استاندارد RFC 8445)

پروتکل ICE به عنوان مدیر اصلی، دو ابزار قبلی را در یک چرخه یکپارچه سازمان دهی می کند:

  1. گردآوری نامزدها: هر رایانه نشانی های ممکن شامل کارت های شبکه محلی، نشانی های بازتابی به دست آمده از STUN و نقاط رله سرور TURN را فهرست می کند.
  2. تبادل اطلاعات: فهرست نامزدها از طریق یک کانال ارتباطی بیرونی میان دو طرف رد و بدل می شود.
  3. سنجش اتصال: دستگاه ها زوج مسیرهای ممکن را بر پایه اولویت مرتب کرده و بسته های آزمایشی STUN را به طور همزمان می فرستند.
  4. انتخاب مسیر نهایی: با تایید برقراری ارتباط دوطرفه روی یک زوج مسیر مستقیم، پروتکل ICE به سرعت ترافیک برنامه را به آن مسیر مستقیم منتقل می کند.

شیوه عملکرد سوراخ کردن درگاه UDP

این روش با بهره گیری از ویژگی های جدول وضعیت دروازه های شبکه عمل می کند.

زمانی که دستگاه داخلی بسته ای به سمت خارج می فرستد، روتر NAT یک رکورد وضعیت موقت در حافظه خود می سازد:

[نشانی محلی: 192.168.1.50:51820] <-> [نشانی عمومی: 203.0.113.10:45000] <-> [مقصد: 198.51.100.25:51820]

این رکورد تا پایان زمان انقضای موقت (بین 30 تا 120 ثانیه) باز می ماند. در این بازه، ورود بسته های پاسخ از مقصد مجاز شمرده می شود.

گام های هماهنگ برای باز کردن مسیر

گام 1: گره A بسته ای به نشانی عمومی گره B می فرستد.
       دروازه NAT A رکورد وضعیت را ثبت می کند.
       بسته به دروازه B می رسد و حذف می شود (هنوز رکوردی در B نیست).

گام 2: همزمان گره B نیز بسته ای به نشانی عمومی گره A ارسال می کند.
       دروازه NAT B رکورد وضعیت را ثبت می کند.
       بسته به دروازه A می رسد.

گام 3: دروازه NAT A جدول را نگاه می کند و می بیند گره A پیش تر به همین
       نشانی پیام فرستاده است؛ بنابراین بسته گره B را عبور می دهد.

گام 4: گره A پاسخ می دهد و دروازه B نیز بسته را مجاز می شمارد.
       مسیر مستقیم دوطرفه UDP میان دو دستگاه هموار می گردد.

به این ترتیب هر دو دروازه بسته های ورودی را پاسخی به تقاضای قبلی دستگاه داخلی خود قلمداد کرده و امکان انتقال دوطرفه بدون نیاز به سرور واسط میسر می شود.

مقایسه شبکه های توزیع شده P2P و معماری کارساز-کارگیر (Client-Server)

در حوزه ارتباطات امن دو رویکرد ساختاری پدیدار شده است:

شاخص شبکه های همتا به همتا (مانند Tailscale) معماری کارساز-کارگیر (VPNRice)
آرایش شبکه اتصالات توزیع شده میان تک تک اعضا شبکه ای از دروازه های پرسرعت Anycast
نیاز به سوراخ کردن NAT برای هر دو گره الزامی است نیاز نیست؛ تنها یک اتصال خروجی ساده انجام می شود
مواجهه با NAT متقارن اتکا به رله های میانی با افزایش زمان پینگ مسیریابی پایدار Anycast بدون پرش های اضافی
حفظ محرمانگی نشانی IP اعضا نشانی واقعی اینترنت خانگی یکدیگر را می بینند نشانی واقعی به طور کامل پشت دروازه ها حفظ می شود
پایداری در شبکه همراه اختلال مکرر در جابه جایی میان دکل های مخابراتی سیگنال Keepalive وضعیت نشست را پیوسته حفظ می کند

در مدل های تمام همتا، اتصال ده دستگاه به یکدیگر نیازمند باز نگه داشتن 45 تونل ارتباطی جداگانه است. با ورود به شبکه های اینترنت همراه که از NAT متقارن استفاده می کنند، فرایند باز کردن مستقیم پورت ها دچار اختلال شده و ترافیک به سمت سرورهای رله هدایت می شود. همچنین نشانی خانگی هر کاربر برای سایر اعضای شبکه نمایان می گردد.

در مقابل، در ساختار مدرن کارساز-کارگیر مسئله عبور از موانع شبکه به شکلی بنیادی حل شده است. از آنجا که سرور دارای نشانی عمومی مشخص و درگاه ثابت است، روتر خانگی ترافیک را به عنوان یک ارتباط خروجی معمولی شناسایی کرده و پاسخ ها را بدون نیاز به اقدامات پیچیده عبور می دهد.

اهمیت پارامتر PersistentKeepalive در پروتکل WireGuard

یکی از علل بنیادین قطع شدن ارتباطات رمزگذاری شده، بسته شدن ناگهانی رکورد درگاه توسط دروازه های شبکه در زمان عدم تبادل داده است.

بسیاری از مودم ها در صورت نبود ترافیک پس از 30 ثانیه رکورد مربوطه را پاک می کنند. با پاک شدن رکورد، سرور قادر به ارسال بسته های جدید به دستگاه کاربر نخواهد بود تا زمانی که کاربر دوباره پیامی به خارج بفرستد.

پروتکل WireGuard با معرفی پارامتر PersistentKeepalive این مشکل را برطرف ساخته است:

[Interface]
PrivateKey = aaaaaa...
Address = 10.8.0.2/24
DNS = 10.8.0.1

[Peer]
PublicKey = bbbbbb...
Endpoint = 198.51.100.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

با تنظیم PersistentKeepalive = 25، دستگاه هر 25 ثانیه یک بسته خالی 32 بایتی رمزگذاری شده ارسال می کند. این سیگنال بسیار سبک، درگاه های ارتباطی را در تمامی شبکه های همراه و سازمانی به صورت دائمی باز نگاه می دارد، بدون آنکه بر مصرف شارژ باتری تاثیر منفی بگذارد.

ساختار پایدار ارتباطی و امنیت در VPNRice

زیرساخت ارتباطی VPNRice فناوری های لایه سوم را در دل پروتکل اختصاصی RiceGuard به کار بسته است. با تکیه بر مجموعه سرورهای Anycast، ارتباطات کاربران به شکل پایدار و بدون برخورد با چالش های ناشی از ترجمه نشانی های شبکه به مقصد هدایت می شوند.

پروتکل RiceGuard از سازوکار تطبیقی هوشمند برای ارسال سیگنال های Keepalive بهره می گیرد و هماهنگ با رفتار اپراتورهای شبکه زمان بندی ارسال را تنظیم می کند. در تمام مدت، نشانی واقعی دستگاه ها و خصوصیات هویتی آن ها پشت درگاه های توزیع شده پنهان می ماند تا حریم خصوصی حفظ گردد.

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