صدمة

📅 آخر تحديث: ٢٨ يوليو ٢٠٢٦
✍️ نُشر في: ٢٨ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

STUN ( أدوات اجتياز الجلسة لـ NAT ؛ في الأصل اجتياز بسيط لبروتوكول بيانات المستخدم (UDP) من خلال مترجمي عناوين الشبكة ) عبارة عن مجموعة موحدة من الأساليب، بما في ذلك بروتوكول الشبكة، لاجتياز بوابات مترجم عناوين الشبكة (NAT) في تطبيقات الصوت والفيديو والرسائل في الوقت الحقيقي وغيرها من الاتصالات التفاعلية.

يُعدّ STUN أداةً تستخدمها بروتوكولات أخرى، مثل بروتوكول إنشاء الاتصال التفاعلي (ICE) وبروتوكول بدء الجلسة (SIP) و WebRTC . وهو يُتيح للأجهزة المضيفة اكتشاف وجود مُترجم عناوين الشبكة (NAT)، واكتشاف عنوان بروتوكول الإنترنت (IP) ورقم المنفذ المُخصصين، وعادةً ما يكونان عامين، واللذين خصصهما NAT لتدفقات بروتوكول بيانات المستخدم (UDP) الخاصة بالتطبيق إلى الأجهزة المضيفة البعيدة. ويتطلب هذا البروتوكول مساعدةً من خادم شبكة تابع لجهة خارجية (خادم STUN) موجود على الجانب المقابل (العام) من NAT، وعادةً ما يكون الإنترنت العام .

أُعلن عن STUN لأول مرة في RFC 3489 عام 2003؛ [ 1 ] وتم تغيير العنوان في مواصفات مجموعة محدثة من الطرق نُشرت باسم RFC 5389 عام 2008، مع الاحتفاظ بنفس الاختصار. [ 2 ]

تاريخ

خوارزمية توصيف NAT الأصلية لـ RFC 3489

أُعلن عن بروتوكول STUN لأول مرة في RFC 3489 عام 2003. [ 1 ] حددت المواصفات الأصلية خوارزمية لتوصيف سلوك NAT وفقًا لسلوك تعيين العناوين والمنافذ. لم تكن هذه الخوارزمية فعّالة بشكل موثوق، وكانت قابلة للتطبيق فقط على مجموعة فرعية من أجهزة NAT المُستخدمة. تتكون الخوارزمية من سلسلة من الاختبارات التي يُجريها التطبيق. عندما ينتهي المسار في المخطط بمربع أحمر، يكون اتصال UDP غير ممكن، وعندما ينتهي المسار بمربع أصفر أو أخضر، يكون الاتصال ممكنًا. أثبتت طرق RFC 3489 عدم كفاءتها في التعامل مع العدد الكبير من تطبيقات NAT المختلفة وسيناريوهات التطبيقات الموجودة في شبكات الإنتاج. تم تحديث بروتوكول STUN وطريقته في RFC 5389، مع الاحتفاظ بالعديد من المواصفات الأصلية كمجموعة فرعية من الطرق، ولكن تم حذف بعضها الآخر.

تم تغيير العنوان في مواصفات مجموعة محدثة من الأساليب نُشرت تحت اسم RFC 5389 في عام 2008، مع الاحتفاظ بنفس الاختصار. [ 2 ]

تصميم

STUN أداةٌ لبروتوكولات الاتصالات تُستخدم لاكتشاف وتجاوز مُترجمات عناوين الشبكة الموجودة في مسار الاتصال بين نقطتي اتصال. وهي مُصممة كبروتوكول عميل-خادم خفيف الوزن ، لا يتطلب سوى مكونات استعلام واستجابة بسيطة، مع خادم طرف ثالث موجود على شبكة عامة يسهل الوصول إليها، عادةً الإنترنت . يتم تنفيذ جانب العميل في تطبيق الاتصالات الخاص بالمستخدم، مثل هاتف بروتوكول نقل الصوت عبر الإنترنت (VoIP) أو برنامج مراسلة فورية.

يعمل البروتوكول الأساسي على النحو التالي: يرسل العميل، الذي يعمل عادةً داخل شبكة خاصة ، طلب ربط إلى خادم STUN على الإنترنت العام. يستجيب خادم STUN برسالة نجاح تحتوي على عنوان IP ورقم منفذ العميل، كما يراه الخادم. يتم إخفاء النتيجة باستخدام عملية XOR (أو الحصرية) لتجنب ترجمة محتوى الحزمة بواسطة بوابات طبقة التطبيق (ALGs) التي تُجري فحصًا عميقًا للحزم في محاولة لتنفيذ طرق بديلة لاجتياز NAT.

تُرسل رسائل STUN في حزم بروتوكول بيانات المستخدم (UDP). ولأن UDP لا يوفر نقلًا موثوقًا ، تُحقق الموثوقية من خلال إعادة إرسال طلبات STUN التي يتحكم بها التطبيق. لا تُطبق خوادم STUN أي آلية موثوقية لاستجاباتها. [ 2 ] عندما تكون الموثوقية ضرورية، يُمكن استخدام بروتوكول التحكم في الإرسال (TCP)، ولكنه يُضيف عبئًا إضافيًا على الشبكة. في التطبيقات الحساسة أمنيًا، يُمكن نقل STUN وتشفيره باستخدام بروتوكول أمان طبقة النقل (TLS).

قد يُحدد التطبيق تلقائيًا خادم STUN مناسبًا للاتصال بنظير معين من خلال الاستعلام من نظام أسماء النطاقات (DNS) عن سجل موارد خادم STUN (لبروتوكول UDP) أو خادم STUNS (لبروتوكول TCP/TLS) ( SRV )، على سبيل المثال stun.udp.example.com . رقم منفذ الاستماع القياسي لخادم STUN هو 3478 لبروتوكولي UDP وTCP، و5349 لبروتوكول TLS. بدلاً من ذلك، يمكن تشغيل TLS على منفذ TCP إذا كان تطبيق الخادم قادرًا على فصل حزم TLS وSTUN. في حال عدم العثور على خادم STUN باستخدام عمليات البحث في DNS، يُوصي المعيار بالاستعلام عن اسم نطاق الوجهة للحصول على سجلات العناوين (A أو AAAA)، والتي ستُستخدم مع أرقام المنافذ الافتراضية. [ 2 ]

بالإضافة إلى استخدام تشفير البروتوكول مع TLS، يحتوي STUN أيضًا على آليات مصادقة مدمجة وآليات سلامة الرسائل عبر أنواع حزم STUN المتخصصة.

عندما يقوم العميل بتقييم عنوانه الخارجي، يمكنه استخدام هذا كمرشح للتواصل مع النظراء من خلال مشاركة عنوان NAT الخارجي بدلاً من العنوان الخاص، الذي لا يمكن الوصول إليه من النظراء على الشبكة العامة.

إذا كان كلا الجهازين المتصلين موجودين في شبكتين خاصتين مختلفتين، كل منهما خلف جدار حماية NAT، فيجب عليهما التنسيق لتحديد أفضل مسار اتصال بينهما. قد تقيّد بعض سلوكيات NAT اتصال الأجهزة حتى عند معرفة الربط العام. يوفر بروتوكول إنشاء الاتصال التفاعلي (ICE) آلية منظمة لتحديد مسار الاتصال الأمثل بين جهازين. تم تعريف امتدادات بروتوكول بدء الجلسة (SIP) لتمكين استخدام ICE عند إعداد مكالمة بين جهازين.

القيود

يتم تنفيذ ترجمة عناوين الشبكة عبر عدد من مخططات تعيين العناوين والمنافذ المختلفة، ولا يوجد أي منها موحد.

لا يُعدّ بروتوكول STUN حلاً مستقلاً لتجاوز جدار الحماية NAT، ولا يُمكن تطبيقه في جميع سيناريوهات نشر NAT، كما أنه لا يعمل بشكل صحيح مع جميعها. إنه أداة من بين طرق أخرى، وهو أداة لبروتوكولات أخرى في التعامل مع تجاوز جدار الحماية NAT، وأبرزها بروتوكول TURN ( تجاوز جدار الحماية باستخدام الترحيل NAT ) وبروتوكول ICE ( إنشاء اتصال تفاعلي ).

يعمل بروتوكول STUN مع ثلاثة أنواع من ترجمة عناوين الشبكة (NAT): ترجمة عناوين الشبكة الكاملة ، وترجمة عناوين الشبكة المقيدة ، وترجمة عناوين الشبكة المقيدة بالمنافذ . في حالتي ترجمة عناوين الشبكة المقيدة أو المقيدة بالمنافذ، يجب على العميل إرسال حزمة بيانات إلى نقطة النهاية قبل أن تسمح ترجمة عناوين الشبكة بمرور الحزم من نقطة النهاية إلى العميل. لا يعمل بروتوكول STUN مع ترجمة عناوين الشبكة المتناظرة (المعروفة أيضًا باسم ترجمة عناوين الشبكة ثنائية الاتجاه)، والتي غالبًا ما توجد في شبكات الشركات الكبيرة. نظرًا لأن عنوان IP لخادم STUN يختلف عن عنوان IP لنقطة النهاية، ففي حالة ترجمة عناوين الشبكة المتناظرة، سيكون تعيين NAT مختلفًا لخادم STUN عنه لنقطة النهاية. يوفر بروتوكول TURN نتائج أفضل مع ترجمة عناوين الشبكة المتناظرة.

انظر أيضاً

مراجع