پیمایش با استفاده از رله ها در اطراف NAT

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

این پروتکل می‌تواند با پروتکل کنترل انتقال اطلاعات (TCP) و پروتکل دیتاگرام کاربر (UDP) استفاده شود. استفاده از این پروتکل می‌تواند در برنامه‌های مختلفی که به ارتباطات چندرسانه‌ای نیاز دارند، مانند ویدئوکنفرانس‌ها و تماس‌های تلفنی، مفید باشد.

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

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

مقدمه

ترجمه آدرس شبکه (NAT)، یک مکانیزم است که به عنوان یک اقدام برای کاهش مشکل کمبود آدرس IPv4 در طول گذار به IPv6 عمل می‌کند، همراه با محدودیت‌های مختلف است. بیشترین محدودیت در میان این محدودیت‌ها، این است که NAT بسیاری از برنامه‌های موجود IP را مختل می‌کند و اجرای برنامه‌های جدید را دشوارتر می‌کند. راهنمایی‌ها توسعه داده شده‌اند که توضیح می‌دهند چگونه "پروتکل‌های سازگار با NAT" را ایجاد کنید، اما بسیاری از پروتکل‌ها نمی‌توانند به عنوان آن‌ها ساخته شوند. مثال‌هایی از این پروتکل‌ها شامل برنامه‌های چندرسانه‌ای و به اشتراک گذاری فایل می‌شود.

Session Traversal Utilities for NAT (STUN) یک روش برای برنامه‌ها برای عبور از NAT فراهم می‌کند. STUN به یک مشتری اجازه می‌دهد تا یک آدرس حمل و نقل (یک آدرس IP و پورت) که ممکن است برای دریافت بسته‌ها از یک همتا مفید باشد، بدست آورد. با این حال، آدرس‌های به دست آمده توسط STUN ممکن است توسط همه همتاها قابل استفاده نباشند. این آدرس‌ها بسته به شرایط توپولوژیکی شبکه کار می‌کنند. بنابراین، STUN به تنهایی نمی‌تواند یک راه‌حل کامل برای عبور از NAT فراهم کند.

پس NAT یا ترجمه آدرس شبکه و ابزارهایی که برای کمک به عبور از آن ارائه می‌شود، را بررسی نمودیم.

NAT یک مکانیزم است که در شبکه‌های کامپیوتری برای ترجمه آدرس‌های IP استفاده می‌شود، به طور خاص در مواقعی که ما برای برقراری ارتباط بین دستگاه‌هایی که در شبکه‌های مختلف هستند، از آدرس‌های عمومی یا global IP استفاده می‌کنیم، NAT به دستگاه‌های شبکه یک آدرس IP عمومی واحد اختصاص می‌دهد که به عنوان نشانی به دستگاه‌ها درون شبکه استفاده می‌شود. اما NAT همچنین محدودیت‌هایی دارد که می‌تواند در برخی مواقع مشکل ساز شود، به عنوان مثال، برنامه‌های موجود IP را مختل می‌کند و اجرای برنامه‌های جدید را دشوار می‌کند. استفاده از ابزار‌هایی مانند STUN می‌تواند به برنامه‌نویسان کمک کند تا ارتباطات را در محیط‌هایی با NAT مدیریت کنند، اما به تنهایی این ابزارها نمی‌توانند مشکلات ارتباطی را کامل حل کنند.یک راه‌حل کامل نیازمند یک وسیله است که به مشتری امکان بدهد یک آدرس حمل و نقل را بدست آورد که از آن بتواند محتوا را از هر همتایی دریافت کند که بتواند بسته‌ها را به اینترنت عمومی ارسال کند. این کار تنها با انتقال داده از طریق یک سروری که در اینترنت عمومی قرار دارد، امکان‌پذیر است. برای این منظور، از پروتکل "گذر از طریق رله‌ها در اطراف NAT" (TURN) استفاده می‌شود که به مشتری این امکان را می‌دهد که آدرس‌ها و پورت‌ها را از چنین رله‌هایی بدست آورد.

اگرچه TURN تقریباً همیشه ارتباط را به یک مشتری فراهم می‌کند، اما برای ارائه‌دهنده سرور TURN منابع زیادی مصرف می‌کند. بنابراین، استفاده از TURN به عنوان آخرین راه‌حل ترجیح داده می‌شود و در صورت امکان، از مکانیسم‌های دیگر مانند STUN یا اتصال مستقیم استفاده می‌شود. برای دست‌یابی به این هدف، می‌توان از متدولوژی ایجاد اتصال تعاملی (ICE) استفاده کرد تا بهترین وسیله اتصال کشف شود.

پروتکل

فرآیند آغاز می‌شود زمانی که یک کامپیوتر مشتری می‌خواهد با یک کامپیوتر همتا برای انجام یک تراکنش داده تماس بگیرد، اما به دلیل اینکه هر دو کامپیوتر مشتری و همتا از NAT مربوطه پشتیبانی می‌شوند، این کار امکان‌پذیر نیست. اگر استفاده از STUN به دلیل یکی از NAT‌ها که NAT همگام است (نوعی NAT است که به عنوان سازگار با STUN شناخته می‌شود) گزینه‌ای نباشد، باید از TURN استفاده شود.

ابتدا، مشتری با یک درخواست "Allocate" به سرور TURN تماس می‌گیرد. این درخواست Allocation از سرور TURN می‌خواهد که برخی از منابع خود را برای مشتری تخصیص دهد تا او بتواند با یک همتا تماس برقرار کند. اگر تخصیص امکان‌پذیر باشد، سرور یک آدرس برای مشتری تخصیص می‌دهد تا او بتواند از آن به عنوان یک رله استفاده کند، و به مشتری یک پاسخ "Allocation Successful" ارسال می‌کند که شامل یک "آدرس حمل و نقل رله تخصیص داده شده" در سرور TURN است.

در مرحله دوم، مشتری یک درخواست "CreatePermissions" را به سرور TURN ارسال می‌کند تا یک سیستم بررسی مجوز برای ارتباطات همتا-سرور ایجاد کند. به عبارت دیگر، زمانی که همتا در نهایت تماس گرفته شده و اطلاعات را به سرور TURN ارسال می‌کند تا به مشتری منتقل شود، سرور TURN از مجوزها استفاده می‌کند تا اعتبار ارتباط همتا-سرور را تأیید کند.

پس از ایجاد مجوزها، مشتری دو گزینه برای ارسال داده‌های واقعی دارد: (1) می‌تواند از مکانیزم ارسال (Send) استفاده کند، یا (2) می‌تواند با استفاده از درخواست "ChannelBind" یک کانال را رزرو کند. مکانیزم ارسال (Send) ساده‌تر است، اما شامل یک هدر بزرگتر، 36 بایت، است که می‌تواند به طور قابل ملاحظه‌ای پهنای باند در یک گفت‌وگوی تلفنی تراکنش TURN را افزایش دهد. در مقابل، روش ChannelBind سبک‌تر است: هدر تنها 4 بایت است، اما نیاز به رزرو یک کانال دارد که نیاز به تجدید نظر دوره‌ای دارد.

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

سرور TURN دیتاگرام UDP همتا را دریافت کرده، مجوزها را بررسی می‌کند و در صورت صحت آن‌ها، آن را به مشتری ارسال می‌کند.

این فرآیند حتی NAT های همگام را بی‌توجه می‌کند زیرا هر دو مشتری و همتا حداقل می‌توانند با سرور TURN صحبت کنند که یک آدرس IP رله برای ارتباط تخصیص داده است.

هرچند TURN مقاوم‌تر از STUN است زیرا به تراورسال انواع بیشتری از NAT‌ها کمک می‌کند، اما یک ارتباط TURN کل ارتباط را از طریق سرور رله می‌گذراند که نیاز به پهنای باند سرور بسیار بیشتری نسبت به پروتکل STUN دارد، که به طور معمول تنها آدرس IP عمومی را حل می‌کند و اطلاعات را به مشتری و همتا برای استفاده در ارتباط مستقیم منتقل می‌کند. به همین دلیل، پروتکل ICE استفاده از STUN را به عنوان اولین راه‌حل الزامی می‌کند و استفاده از TURN را تنها زمانی که با NAT های همگام یا موارد دیگری که استفاده از STUN ممکن نیست روبرو است.

جهت دریافت اطلاعات بیشتر لینک زیر را ببینید

• Interactive Connectivity Establishment

منابع

1. Matthews, Philip; Rosenberg, Jonathan; Mahy, Rohan (April 2010). Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Report).
2. RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, J. Rosenberg (April 2010)
3. RFC 8445, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal, A. Keranen, C. Holmberg Ericsson, J. Rosenberg (July 2018)