ترجمة عنوان الشبكة

ترجمة عنوان الشبكة (بالإنجليزية: Network Address Translation اختصاراً NAT)‏ هو مصطلح يُستعمل لوصف عدد من الآليات التي تستخدم لتبديل مُعرِّفات شبكيَّة، مثل عنوان بروتوكول الإنترنت أو أرقام المنافذ، في رزم البيانات اللاتي تتنقل بين نطاقي عناوين مختلفين يسميان النطاق الداخلي والخارجيّ.[1] طُوِّرت هذه الآلية في عام 1994م كجزء من الاستراتيجية قصيرة الأمد لمعالجة مشكلة استنفاد عناوين بروتوكول الإنترنت.[2]

تبديل عناوين الإصدار الرابع من بروتوكول الإنترنت بحسب تقنية ترجمة عنوان الشبكة.
جزء من سلسلة مقالات حول
بروتوكول الإنترنت
بوابة إنترنت

ترجمة عنوان الشبكة ليست بروتوكولاً بل هي آليَّة عمل، تحصل في موجه يربط بين نطاقي عناوين.[3] تسبق ترجمة العناوين عملية تهيئة للموجه، قد يُزوَّد فيها بأزواج من المُعرفات، تضمُّ شطراً من النطاق الداخلي وشطراً من النطاق الخارجي، وقد يزود بنهجٍ وشروطٍ مُحددة لتشكيل الأزواج آليَّاً ويحدد أيضاً الاتجاه الذي يُسمح فيه بإنشاء جلسة الترجمة.[4] يراقب الموجه بعدها حركة البيانات بين النطاقين، ويبدأ بإنشاء جلسة ترجمة وفقاً للشروط متى ما توافقت مُعرفات رزمة بيانات ما مع أحد الأزواج، وتستمر عملية الترجمة بعد ذلك على رزم الجلسة المتدفقة بكلا الاتجاهين كُلِّها، وتُغلق الجلسة لاحقاً، وتتوقف عملية الترجمة بعدها.[5]

تُصنَّف هذه الآلية إلى أنواع وفقاً لطريقة تشكيل أزواج المُعرِّفات وللاتجاه الذي يُسمح فيه بإنشاء الجلسة، وأول هذه الأنواع هو الترجمة الأساسيَّة، وهي طريقة يُمكن فيها إعداد أزواج ثابتة البِنية من عناوين بروتوكول الإنترنت بين النطاقين، وثانيها هو الترجمة المُتغيَّرة، وفيها يُحدد فضاءٌ للعناوين لكل نطاق، ويجري تشكيل أزواجٍ من النطاقين آليَّاً، وثالثُها هو ترجمة العناوين وأرقام المنافذ، وفيها تشمل الأزواج أيضاً أرقام منافذَ بين النطاقين، وتنضوي الأنواع الثلاثة تحت تصنيف واحد هو الترجمة التقليديَّة، وفيها يمكن إنشاء الجلسة باتجاه واحد فقط، وغالباً ما يكون من النطاق الداخلي إلى الخارجي. ومن الأنواع أيضاً الترجمة ثُنائِيَّة الاتجاه، وهي تستعمل إحدى تقنيات الترجمة التقليديَّة، ولكنَّها تسمح بإنشاء الجلسات بكلا الاتجاهين. في جميع ما سبق، يُمكن أن تترجم مُعرِّفات مصدر الرزمة أو مُعرفات وجهتها، وفقاً لاتجاه حركة الرزمة، ولكن هناك نوعٌ آخر يسمح بإجراء الترجمة للإثنين معاً، ويُسمَّى بالترجمة المُضاعَفة.[6]

هناك مُشكلات عديدة في تطبيق هذه الآليَّة، منها ما هو فلسفيٌ في طبيعته ومنها ما هو تقنيّ. أمَّا الفلسفيّ، ففيه تُخلُّ هذه التقنية بمبدأ الطرفين، وهو أحد المبادئ الرئيسة التي قامت الإنترنت على أساسها.[7] وأمَّا التقنيّ، فمثاله اعتماد تطبيقات عديدة في عملها على المُعرفات التي يجري تبديلها، ويتطلب حل إشكالٍ كهذا إجراء تغيرات عديدة أخرى في ترويسات بروتوكولات هذه التطبيقات.[8] هناك أيضاً جدلٌ غير محسوم حول جدوى استخدام هذه الآليَّة مع الإصدار السادس من بروتوكول الإنترنت.[9]

خلفية عامة
مثال عن عنوان من الإصدار الرابع من بروتوكول الإنترنت.
بنية العنونة الصنفية وفق الإصدار الرابع من بروتوكول الإنترنت.

الإصدار الرابع من بروتوكول الإنترنت

الإصدار الرابع من بروتوكول الإنترنت (بالإنجليزية: Internet Protocol version 4 اختصاراً IPv4)‏ هو بروتوكول تشبيك يعمل في طبقة الشبكة بحسب نموذج الاتصالات المعياري. طوّر هذا البروتوكول في عام 1981م كجزء من عمل وكالة مشاريع البحوث المتطورة الدفاعية، وكان أحد الركائز التي قامت شبكة الإنترنت على أساسها.[10]

يُعنى هذا البروتوكول بوظيفتين أساسيتين هما العنونة والتقطيع. والعنونة هي منح مُعرفات لتمييز مضيف أو مجموعة من المضيفين في الشبكة المحلية أو في الإنترنت، ويُسمَّى العنوان الممنوح عنوان برتوكول الإنترنت.[11] قد يُستخدم العنوان لتمييز مُضيفٍ ما بشكلٍ فريد بعينه، أو لتحديد أعضاء مجموعة من المضيفين الذين يستضيفون العنوان في نفس الوقت، وليس هناك مانع من استضافة المُضيف لأكثر من عنوان بروتوكول إنترنت في نفس الوقت.[12]

يُعرِّف الإصدار الرابع من بروتوكول الإنترنت فضاءً من العناوين يبلغ طول كل منها 32 بتاً، وقسِّم هذا الفضاء بحسب العنونة الصنفية إلى عدد من الأصناف على أساس رياضي، وشمل الصنف الأول، والذي يُسمّى الصنف A، جميع العناوين التي تبدأ بالبت (0) في الخانة الأكثر أهمية، وقُسِّم فضاء هذا الصنف إلى 128 فضاءً جزئياً في كل منها 16777216. أما فضاء الصنف B، فضم جميع العناوين التي تبدأ بالبتين (10)، وقُسِّم فضاء هذا الصنف إلى 16384 فضاءً جزئياً في كل منها 65536 عنواناً. وأما فضاء الصنف C، فضم جميع العناوين التي تبدأ بالبتات (110)، ثم قسم هذا الفضاء إلى 2097152 فضاءً جزئياً في كل منها 255 عنواناً. كما اقتطع من الفضاء الأصلي فضاء مخصص للبث المجموعاتي، وهو الفضاء الذي تبدأ جميع عناوينه بالبتات (1110)، في حين حجز الفضاء الذي تبدأ عناوينه بالبتات (1111) لاستخدامات مستقبلية.[12][13] بالإجمال، هناك 232 أي ما يعادل 4294967296 عنواناً في فضاء الإصدار الرابع من بروتوكول الإنترنت.[14]

استنفاد فضاء عناوين الإصدار الرابع
خط زمني لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.

استنفاد فضاء عناوين الإصدار الرابع (بالإنجليزية: IPv4 address space exhaustion)‏ هو نضوب العناوين الحرة في فضاء الإصدار الرابع من بروتوكول الإنترنت. بدأت هذه المشكلة في مطلع التسعينات مع انتشار الاستخدام التجاري للإنترنت، حيث لوحظ نمو معدل استهلاك فضاء الإصدار الرابع من بروتوكول الإنترنت بشكل أسي، وكانت التوقعات تشير إلى استنفاد الفضاء كاملاً في منتصف التسعينات من القرن العشرين.[15]

لمعالجة هذه المشكلة، شكَّلت مجموعة مهندسي الإنترنت مجموعة عمل التوجيه والعنونة والمعروفة اختصاراً باسم رُوْد (بالإنجليزية: Routing and Addressing اختصاراً ROAD)‏،[16] وقامت هذه المجموعة بتحديد ثلاث مشكلات رئيسة ستعيق نمو الإنترنت في المدى القصير والمتوسط، وهي كالتالي:[17]

  1. استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لعدم وجود فضاء عناوين يناسب مؤسسة متوسطة الحجم، فإمَّا فضاء الصنف C القياسي، الذي يضم 256 عنواناً فقط، أو فضاء الصنف A القياسي الذي يضم ملايين العناوين.
  2. نمو جداول التوجيه في موجهات الإنترنت لتصبح بجاجة إلى قدرات معالجة غير متوافرة بالبرمجيات أو المعدات المتوافرة.
  3. استنفاد فضاء عناوين الإصدار الرابع بشكل نهائي.

وُصفت المشكلتان الأولى والثانية بأنهما قصيرتا الأمد، وكان من المتوقع استفحالهما في الفترة بين العامين 1993 و1995م، على عكس المشكلة الثالثة التي وُصِفت بأنَّها طويلة الأمد.[18] من أجل المشكلتين الأولى والثانية، بدأت مجموعة رُوْد العمل على تطوير استراتيجية قصيرة الأمد لحل هذه المشكلة، فطوَّرت تقنية التوجيه غير الصنفي بين النطاقات، التي نُشر مبدؤها في يونيو من العام 1992م في وثيقة طلب التعليقات RFC 1338[19]، وفي شهر مايو من العام 1994م، طُوِّرت تقنية ترجمة عنوان الشبكة لتكون أحلاً آخر قصير الأمد لمشكلة الاستنفاد،[2] واعتمد هذا الحل بشكل أساسي على استعمال أفضية عناوين محددة سُميت الشبكات الخاصة بشكل غير فريد في عنونة الشبكات المحلية، والاقتصار على استعمال العناوين العامة عند النفاذ إلى الإنترنت فقط.[20] أمَّا في إطار الاستراتيجية طويلة الأمد فقد طوِّر إصدار جديد من بروتوكول الإنترنت، هو الإصدار السادس من بروتوكول الإنترنت، نشر المعيار الأول للبروتوكول في شهر ديسمبر من العام 1995م ووصف بوثيقة طلب التعليقات RFC 1883.[21]

كانت الحلول قصيرة الأمد شديدة الفعاليَّة، فأطالت من عمر الإصدار الرابع من بروتوكول الإنترنت لأكثر من عقدين من الزمن، ولكن الهيئة الناظمة لتحصيص فضاء الإصدار الرابع من بروتوكول الإنترنت، وهي أيانا، استنفذت الفضاء كاملاً في شهر يناير من العام 2011م.[22]

الشبكات الخاصة

الشبكات الخاصة (بالإنجليزية: Private network)‏ هي أفضية جزئيَّة من فضاء الإصدار الرابع من بروتوكول الإنترنت، وهي محجوزة من أجل الاستعمال المحلي فقط ولا يُعلن عنها في الإنترنت.[23] حجزت أيانا، وهي الهيئة الناظمة لتحصيص فضاء بروتوكول الإنترنت، ثلاثة أفضية جزئية هي 10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16.[24] يُسمَّى الفضاء الأول المجال ذي البتات الأربعة والعشرين (بالإنجليزية: 24 bit block)‏، والثاني بالمجال ذي البتات العشرين والثالث بالمجال ذي البتات الست عشرة، وهذه الأطوال هي أطوال قسم المُضيف في تمثيل البادئة للمجالات الثلاثة. يُكافِئ المجال الأول شبكة قياسية من الصنف A ويُكافئ الثاني 16 شبكة قياسية متتاليَّة من الصنف B، ويُكافِئ الثالث 256 شبكة جزئية قياسيَّة من الصنف.[25]

اسم المجالامتداد المجالتمثيل البادئة
(القناع)		طول قسم البادئةطول قسم المضيفعدد عناوين المجالالمُكافئ في العنونة الصنفيَّة
ذو البتات الأربعة والعشرين10.0.0.0 - 10.255.255.2558/
(255.0.0.0)		82416777216فضاء قياسي من الصنف A
ذو البتات العشرين172.16.0.0 - 172.31.255.25512/
(255.240.0.0)		1220104857616 فضاء قياسي متتالٍ من الصنف الصنف B
ذو البتات الست عشرة192.168.0.0 - 192.168.255.25516/
(255.255.0.0)		161665536256 فضاء قياسي متتالٍ من الصنف C

أرقام المنافذ

رقم المنفذ (بالإنجليزية: Port number)‏ هو مُعرِّف رقمي يُستخدم لتمييز الاتصال وفق حزمة بروتوكولات الإنترنت، يبلغ طوله 16 بتاً أي بالإمكان توليد 216 = 65536 رقم منفذ متمايز.[26] بصورةٍ عامَّةٍ، في شبكات البيانات، تخدم المنافذ غرضين أساسيين، أولهما إتاحة آلية للتمييز بين جلسات الاتصال المختلفة التي قد تجري بين طرفين، وثانيها مساعدة بروتوكول النقل في تحديد بروتوكول التطبيق الذي يستخدمه،[27] ولهذا أهمية خاصة في عمليتي التغليف وفك التغليف. بالإضافة لذلك، يُستعمل رقم المنفذ جنباً إلى جنب مع عنوان بروتوكول الإنترنت لتوليد مقبس الشبكة (بالإنجليزية: Socket)‏، ويمكن تمييز أي اتصال بشكل فريد بحسب قيم المقبسين على طرفيه.[28]

يُقسَّم مجال أرقام المنافذ إلى ثلاث أقسام فرعيَّة هي: أرقام منافذ النظام ومجالها (0-1023)، وأرقام منافذ المستخدم ومجالها (1024-49151)، وأرقام المنافذ الخاصة (49152-65535). تشرف المجموعة التوجيهية لهندسة الإنترنت (IESG) على منح أرقام منافذ النظام، في حين تدير هيئة أرقام الإنترنت المُخصصة، أي أيانا، عملية منح أرقام منافذ المستخدم، وأمَّا أرقام المنافذ الخاصة فلا تُمنح.[29]

الوصف

تعاريف واصطلاحات

تُعرِّف وثيقة طلب التعليقات RFC 2663، المعنونة: "اعتبارات واصطلاحات لترجمة عنوان الشبكة"(1) المفاهيم التاليَّة:[30]

  • نطاق عناوين (بالإنجليزية: Address realm)‏: هو قطاع من الشبكة تُمنح عناوين بروتوكول الإنترنت فيه للمُضيفين بشكلٍ فريد، أي لا يمكن أن يُمنح مُضيفان نفس العنوان في هذا النطاق.
  • نطاق العناوين الخارجي:(2) هو نطاق عناوين تديره أيانا أو سجلات إنترنت أدنى في هرمية تحصيص العناوين.
  • نطاق العناوين الداخلي:(3) هو نطاق عناوين خاصَّة، ويمكن استعمال نطاقات كهذه محليَّاً من قِبَل أكثر من مُنظمة بنفس الوقت وبشكل مستقلٍ، أي بدون مراجعة هيئة تحصيص العناوين أو سجلات الإنترنت الإقليمية.
  • التوجيه غير المرئيّ (بالإنجليزية: Transparent routing)‏: هو توجيهٌ رزم البيانات بين نطاقي عناوين مختلفين، أي داخليّ وخارجيّ. ويشمل ذلك قيام الموجه الذي يُجري عملية الترجمة بتغيير محتويات ترويسة بروتوكول الإنترنت وبروتوكول التحكم بالنقل. وهو يختلف عن التوجيه التقليدي الذي يحصل ضمن نطاق عناوين واحد. يُوصف هذا التوجيه بأنه غير مرئي لأنه غير مُلاحَظ من قبل المُضيفين، فهي لا تدرك حصوله، أي أنَّها لا تدرك تغيير المحتويات الحاصل أثناء عملية الترجمة.
  • الجلسة (بالإنجليزية: Session)‏ الجلسة هي حركة البيانات التي تخضع لعملية الترجمة. واتجاه الجلسة فهو اتجاه هذه الحركة عند البدء، أي من أيِّ نطاق بدأت ؟ ونحو أيّ نطاقٍ تتجه ؟ بعد إنشاء الجلسة، فإن حركة البيانات ستشمل تدفقاً لرزم بيانات بروتوكول الإنترنت بالاتجاهين، بغض النظر عن اتجاه الجلسة. تجري ترجمة عناوين الشبكة على الجلسة كاملةً، ويحدد اتجاه تدفق الجلسة باتجاه تدفق أول رزمة بيانات فيها.

مبدأ العمل

تعمل ترجمة عناوين الشبكة على تغيير قيم حقول محددة في ترويسات رزم البيانات التي تمر عبر الموجه الذي يقوم بالترجمة، يُمكن أن تحصل عملية الترجمة على رزم البيانات التي تعبر الموجه بكلا الاتجاهين.[31] تشمل الحقول التي يُبدل محتواها حقول عناوين المصدر أو الوجهة أو كليهما في ترويسة بروتوكول الإنترنت وحقول عناوين رقم منفذ المصدر أو الوجهة أو كليهما في ترويسة بروتوكول النقل المستعمل، وحقل مُعرِّف الاستعلام في ترويسة بروتوكول رسائل التحكم في الإنترنت.[30] يُسبب تغيير محتوى ترويسة بروتوكول الإنترنت أو بروتوكول النقل المُستعمل الحاجة إلى إعادة حساب قيمة حقل التحقق الجمعي (بالإنجليزية: Checksum)‏ في أي ترويسة جرى تعديل قيمة أحد حقولها.[32]

تعمل تقنية ترجمة عنوان الشبكة عبر آلية مكونة من ثلاث مراحل كما يأتي:[5]

  1. مرحلة التهيئة: وتشمل بناء أزواج من محددات الاتصال، أي عناوين إنترنت أو أرقام منافذ أو الاثنين معاً، ويتألف كل زوج من جزأين: جزءٌ من النطاق الداخليّ وجزءٌ من النطاق الخارجيّ، وتشمل عملية التهيئة أيضاً تحديد الاتجاه الذي يُسمح فيه بإنشاء الجلسة. بعد ذلك، يرتبط كل زوج بعلمٍ لبيان حالته، ويكون العلم مرفوعاً، أي قيمته مساوية للواحد، فقط إذا كان هناك جلسة جارية ترتبط بهذا الزوج، وبخلاف ذلك فقيمته صفريَّة.
  2. مرحلة المراقبة والترجمة: ويجري فيها مراقبة حركة البيانات عبر المُوجِّه، فإذا مرَّت رزمة بيانات كانت معلومات الترويسة فيها مُتوافِقة مع أحد الأزواج المُهيَّئة في المرحلة السابقة، وكان اتجاه حركة الرزمة متوافق مع اتجاه إنشاء الجلسة أيضاً، فإن جلسة جديدة ستبدأ، ويقوم الموجه بتبديل قيم حقول الترويسة بما يتوافق مع التهيئة، ويُرفع علم بيان الحالة في الزوج ذي الصلة، ويلي ذلك إجراء الترجمة على رزم بيانات الجلسة جميعها وبالاتجاهين.
  3. مرحلة التحرير: عندما تُغلق الجلسة، يُخفَض علم بيان الحالة، ويُحرر زوج العناوين، ويُعاد ثانيةً إلى وضع المراقبة.

التصنيف

يتضمن أبسط أشكال الترجمة تبديل عنوان مصدر رزمة بروتوكول الإنترنت، وتحديداً استبدال عنوان المصدر الخاصّ المحليّ بعنوان فريد عالميَّاً، وتبدو الرزمة بعد ذلك وكأنَّها قادمة من العنوان الجديد. وفي شكل أكثر تعقيداً، بإمكان عملية الترجمة أن تستبدل عنوان مصدر الرزم القادمة من شبكة الإنترنت إلى شبكة محليَّة خاصَّة، فتبدو بعد ذلك كأنَّها قادمة من وجهة محليَّة فيها، ويُمكن أيضاً أن تشمل العملية استبدال عنواني المصدر والوجهة معاً.[33]

الترجمة التقليدية

ترجمة العناوين التقليدية (بالإنجليزية: Traditional NAT)‏: هي الشكل الأبسط من ترجمة العناوين، وهي تسمح لمُضيفي عناوين نطاق داخليّ بالاتصال مع مضيفي عناوين نطاق خارجيّ. تحصل عملية الترجمة في مُوجِّه يصل بين النطاقين، ويقوم بالتوجيه غير المرئي بالنسبة للمُضيفين. في هذا النوع من الترجمة، تكون الجلسات المنشأة وحيدة الاتجاه، أي بالإمكان إنشاؤها باتجاه واحد فقط، وغالباً ما يكون من النطاق الداخلي نحو الخارجي. يجب الانتباه إلى أن حركة رزم بيانات وعملية ترجمة العناوين بعد الإنشاء تكون بكلا الاتجاهين، أي أن الشرط السابق هو لاتجاه إنشاء الجلسة وليس لحركة رزم البيانات فيها.[34]

تشمل ترجمة العناوين التقليدية النمطين التالييين:[35]

  1. الترجمة الأساسية لعناوين الشبكة (بالإنجليزية: Basic NAT)‏ وتحصل عملية الترجمة فيها على عناوين مصادر ووجهات رزم بروتوكول الإنترنت. وتُصنَّف إلى نوعين وفقاً للطريقة التي يجري فيها تحديد أزواج العناوين التي تترجم بين النطاقين الداخليّ والخارجيّ، وهما:[36]
    1. ترجمة عناوين الشبكة الثابتة (بالإنجليزية: Static NAT)‏
    2. ترجمة عناوين الشبكة المُتغيَّرة (بالإنجليزية: Dynamic NAT)‏
  2. ترجمة عناوين الشبكة وأرقام المنافذ (بالإنجليزية: Network Address Port translation اختصاراً NAPT)‏

الثابتة
طريقة عمل ترجمة العناوين الثابتة.

في الترجمة الثابتة، يُهيَّأ المُوجِّه الذي يقوم بعمليَّة الترجمة بعددٍ صحيح N من أزواج عناوين بروتوكول الإنترنت، أي (X1,Y1) و(X2,Y2) حتى (XN,YN)، حيث X هو عنوان بروتوكول الإنترنت من نطاق العناوين الداخليّ وY هو عنوان بروتوكول إنترنت من نطاق العناوين الخارحيّ. بالإضافة لذلك، يُهيَّأ المُوجِّه أيضاً بالاتجاه المسمُوح لإنشاء الجلسة، وهو في حالة الترجمة التقليديَّة من النطاق الداخليّ إلى الخارجي. يقوم المُوجِّه بعدها بمراقبة حركة البيانات المارة عبره لأجل إنشاء جلسة ترجمة متوافِقة مع أزواج العناوين والاتجاه المسموح. بعد الإنشاء، يُعدِّل المُوجِّه عنوان المصدر في رزم البيانات القادمة من النطاق الداخلي ويغير قيمته إلى العنوان الخارجيَّ وفقاً لقيم الأزواج التي هُيِّئ بها، أما في الرزم القادمة من النطاق الخارجي إلى الموجه، والتي تكون وجهتها العنوان الخارجي، فيُعدِّل عنوان الوجهة فيها ويُغيّره إلى العنوان الداخلي وفقاً لقيم الأزواج السابقة نفسها، وذلك بشرط أن تكون الجلسة قد أُنشِئَت قبلاً.[37][38]

يُوصف هذا النوع من الترجمة بأنَّه ثابِت، لأنَّ أزواج العناوين التي تجري الترجمة بمقتضاها ثابتة البِنية لا تتغير بشكلٍ آليّ، ويُوصَف أيضاً بأنَّه ترجمةُ واحدٍ إلى واحدٍ (بالإنجليزية: One-to-one)‏ لأنَّ المُوجِّه تقوم بترجمة عنوان خاصٍّ واحد من النطاق الداخليّ إلى عنوان عام واحد من النطاق الخارجيّ أو بالعكس.[39]

المتغيرة
طريقة عمل ترجمة العناوين المُتغيَّرة.

تُنْشَأ جلسات الترجمة المُتغيَّرة انطلاقاً من النطاق الداخليّ فقط، يكون هناك عدَّة عناوين من النطاق الخارجي (Y1 ... YN)، بالإضافة إلى مجموعة من عناوين النطاق الداخلي (X1 ... XM) حيث M وN هي أعداد صحيحة موجبة تُمثِّل عدد العناوين في النطاقين الداخليّ والخارجيّ على الترتيب. ويكون شرط بدء الجلسة هو أن ينتمي عنوان مصدر الرزمة إلى النطاق الداخليّ، أي (X1 ... XM). وعند بدء جلسة ترجمة، انطلاقاً من النطاق الداخلي، يقوم المُوجِّه الذي ينفذ عملية الترجمة باختيار عنوان ما من مجموعة عناوين الخارجي Yk ويربطها مع عنوان مصدر الرزمة Xi، ثُمّ يُشكِّل منها زوجاً (Xi,Yk) آليَّاً، ويحتفظ به في جدول الترجمة الآلية، وتجري عملية تبديل عناوين مصادر الرزم البيانات في الجلسة ذات الصلة بناءً على قيم هذا الزوج، وعند إغلاق الجلسة، يجري تحرير العناوين لإعادة استخدامها مرة أخرى في تشكيل أزواج جديدة. يكون شطرا أي زوج غير ثابتين، أي بالإمكان أن يرتبط أحد الشطرين مع عدة أشطر أخرى، في جلسات متنوعة متتالية، والعكس صحيح، وذلك عوضاً عن اعتماد أزواج محددة الأشطر، كما هو الحال في الترجمة الثابتة.[40]

قد تكون عناوين المجموعتين السابقتين مُختلِفة العدد، وغالباً ما تكون أعداد العناوين المتاحة لتشكيل الأزواج في النطاق الداخليّ أكبر من تلك المتاحة في النطاق الخارجيّ، ويقوم المُوجِّه عندها ببناء الأزواج من عناوين النطاقين وفق ما سبق حتى استنفاد النطاق الأصغر حجماً، ولا يمكن بعدها إنشاء أيّ جلسةٍ جديدةٍ حتى يتحرر شطرا زوجٍ محجوزٍ من جلسةٍ سابقةٍ. تُوصف هذه الترجمة أيضاً بأنَّها ترجمة واحد إلى واحد، لأنَّها تقوم بترجمة عنوان خاص واحد من النطاق الداخلي إلى عنوان عام واحد من النطاق الخارجي.[41]

العناوين وأرقام المنافذ
طريقة عمل ترجمة المنافذ.

في ترجمة أرقام المنافذ، ومن أجل الرزم الواردة إلى الموجه من نطاق العناوين الداخليّ باتجاه النطاق الخارجيّ، يُبدَّل عنوان المصدر في الرزمة X مع رقم منفذ المصدر فيها x بعنوان مصدر جديد هو Y ورقم منفذ ’خر هو y، أخذاً بالحسبان أن العنوان X من النطاق الداخلي والعنوان Y هو عنوان من النطاق الخارجي، ويُعبَّر عن عملية الترجمة السابقة بالشكل: X:x → Y:y. يمكن أن تجري العملية السابقة على فضاء محدد من النطاقين الداخلي والخارجي، وأن تُحدَد الأزواج بشكلٍ ثابتٍ أو آليّ.[42]

هناك شكلٌ خاصٌّ من ترجمة أرقام المنافذ، يُسمَّى التحميل الزائد لترجمة أرقام المنافذ (بالإنجليزية: PAT overloading)‏، وفيها يُستخدم عنوان مصدر واحد فقط من النطاق الخارجيّ في عملية الترجمة. فلو كانت أزواج العناوين وأرقام المنافذ في النطاق الداخليّ هي X1:x1 وX2:x2 وX3:x3، وبدأ كل منها جلسةً ترجمة، فإنَّها ستترجم وفقاً لعملية التحميل الزائد إلى Y:y1 وY:y2 وY:y3 على الترتيب. ويمكن لهذه الطريقة من الترجمة أن تسمح، نظريَّاً، بترجمة ما يزيد عن 65 ألفاً من العناوين الداخلية باستعمال عنوان خارجيّ وحيد، وتقلل بذلك من استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.[43] يُمكن أن تجري عملية الترجمة على مُعرِّف الاستعلام في ترويسة بروتوكول رسائل التحكم في الإنترنت بنفس الطريقة السابقة أيضاً.[44]

الترجمة ثنائية الاتجاه
مثال عن كيفية عمل الترجمة ثنائية الاتجاه، في هذا النوع من الترجمة بالإمكان إنشاء الجلسة من النطاق الداخلي نحو النطاق الخارجي وبالعكس أيضاً.

ترجمة العناوين ثُنائيَّة الاتجاه (بالإنجليزية: Bidirectional NAT أو Two-way NAT)‏ وهي شكل من أشكال ترجمة عناوين الشبكة يسمح بإنشاء الجلسات بدءاً من مُضيفين في نطاقي العناوين كليهما، أي انطلاقاً من النطاق الداخليّ والخارجيّ. مع أخذ ذلك بالحسبان، فإنَّ عملية الترجمة ثُنائيَّة الاتجاه تخضع لنفس القواعد المستعملة في الترجمة التقليديَّة سواءً لجهة كيفيَّة إنشاء أزواج العناوين التي ستُترجم أو لجهة ما يجري ترجمته، أي عناوين أو أرقام منافذ أو كليهما.[45]

الترجمة المُضاعفة
كيفية عمل ترجمة عناوين الشبكة المضاعفة. في هذه الحالة يقوم الموجه الذي يقدم خدمة الترجمة بتبديل عنواني المصدر والوجهة معاً في رزمة البيانات التي يجري ترجمتها.

ترجمة العناوين المضاعفة (بالإنجليزية: Twice NAT)‏(4) وهي شكل من أشكال ترجمة عناوين الشبكة، وفيه يُعدَّل عنوانا المصدر والوجهة معاً في رزمة البيانات التي يجري ترجمتها، وهي تُوصف بالمُضاعفة تمييزاً لها عن الترجمة التقليديَّة وعن الترجمة ثُنائيَّة الاتجاه.[45]

تضيف هذه الترجمة بُعداً جديداً لتصنيف العناوين، وهو النطاق الذي تستخدم فيه العناوين، فإذا كان العنوان مُستخدماً في نطاقه فهو عنوان محليّ، وإن كان مُستخدماً خارج نطاقه فهو عنوان عالميّ، وبإضافة هذا للتصنيف الذي يقسم العناوين على أساس موقع مُضيفها يمكن تعريف التصانيف التالية:[46][47](5)

  • العنوان الداخليّ المحليّ: وهو عنوان موجود في النطاق الداخليّ، وهو يُستعمل في نفس النطاق.
  • العنوان الداخليّ العالميّ: وهو عنوان موجود في النطاق الداخليّ وهو يُستعمل خارج النطاق. أي هو عنوان لمُضيف داخليّ، ولكنَّه مرئيٌّ في النطاق الخارجيّ.
  • العنوان الخارجيّ المحليّ: وهو عنوان موجود في النطاق الخارجيّ، وهو يُستعمل في نفس النطاق.
  • العنوان الخارجيّ العالميّ: وهو عنوان موجود في النطاق الخارجيّ وهو يُستعمل خارج النطاق. أي هو عنوان لمُضيف خارجيّ، ولكنَّه مرئيٌّ من النطاق الداخليّ.

يُهيَّأ الموجه بزوجين من عناوين المصدر والوجهة، الزوج الأول هو (X1,Y1) حيث X1 هو عنوان داخلي محلي وهو عنوان مصدر الرزمة التي ستترجم، وY1 هو عنوان خارجي عالمي، وهو عنوان وجهة الرزمة التي ستتُرجم. والزوج الثاني هو (X2,Y2) حيث X2 هو عنوان داخلي عالمي وهو عنوان مصدر الرزمة بعد الترجمة، وY1 هو عنوان خارجي عالمي، وهو عنوان وجهة الرزمة بعد الترجمة. بعد ذلك، إذا وردت للموجه رزمة من النطاق الداخلي نحو النطاق الخارجي، وكان عنوان مصدرها هو X1 وعنوان وجهتها هو Y1، فإن الموجه سيقوم بتعديل العنوانين إلى X2 وY2 على الترتيب، أي (X2,Y2) → (X1,Y1).[48]

اعتبارات إضافية

بروتوكول رسائل التحكم في الإنترنت

بروتوكول رسائل التحكم في شبكة الإنترنت هو (بالإنجليزية: Internet Control Message Protocol اختصاراً ICMP)‏ هو بروتوكول تبليغ عن الأخطاء يعمل مع بروتوكول الإنترنت ويقدّم مجموعة من الوظائف التي تُستخدم في إدارة الشبكة والتحري عن الأخطاء فيها، أشهرها أمر التحقق من الاتصال Ping الذي يُستعمل للتحقق من اتصال مضيف ما مع الشبكة.[49] وصف هذا البروتوكول في وثيقة طلب التعليقات RFC 792.[50]

تُصنَّف رسائل هذا البروتوكول إلى صنفين: رسائل الأخطاء ورسائل الإعلام. قد تحتوي رسائل الأخطاء على ترويسة بروتوكول إنترنت كاملة أو جزئية تضمّ فيها عناوين بروتوكول إنترنت، وإذا انتقلت الرسالة بين نطاقين، وأجريت ترجمة عناوين الشبكة عليها، يجب ترجمة عناوين الشبكة المحمولة فيها أيضاً. أما في رسائل الإعلام، فيجب ترجمة مُعرِّف الاستعلام بشكل مشابه لترجمة أرقام المنافذ. في كلتا الحالتين، ونتيجة لتغيير محتويات الترويسة، يجب إعادة حساب حقل التحقق الجمعي فيها.[51]

وُصِفت المُتطلبات السلوكية اللازمة لعمل ترجمة عنوان الشبكة مع بروتوكول رسائل التحكم في الإنترنت في وثيقة طلب التعليقات RFC 5508.[52]

الإصدار السادس من بروتوكول الإنترنت
وفقاً لمبدأ الطرفين، تكون الشبكة مسؤولة عن تأمين الاتصال بين الطرفيّات فقط، أمّا أيُّ شكلٍ من أشكال الذكاء فيوجد في الطرفيات.

هناك حالة من الجدل حول استعمال ترجمة عنوان الشبكة مع الإصدار السادس من بروتوكول الإنترنت، البعض يُحاجج أن استعمال الترجمة يُلغى مبدأً أساسيَّاً من المبادئ التي قامت عليها الإنترنت، وهو مبدأ الطرفين، ويقول بأنَّ تطوير واستعمال ترجمة عنوان الشبكة كان حلاً آنيَّاً لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت. أمَّا الفريق المؤيد للاستعمال فيُجادل بأنَّ استعمال الترجمة يُقدِّم عدد من المنافع والتسهيلات لا بديل آخر لها أو يصعب التخليّ عنها.[9][53]

يشير الفريق المعارض لاستخدام تقنية الترجمة مع الإصدار السادس إلى زوال السبب الذي أدى إلى تطويرها أساساً، وهو محدودية فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت وسرعة استنفاذه، ويستندون في دفاعهم إلى حقيقة أن تطبيق ترجمة عناوين الشبكة تخلق حاجزاً يُوضع في وجه شفافية الشبكة، ولذلك فإنَّ وثيقة طلب التعليقات RFC 4924 تُوصي بتجنب استعمال ترجمة عنوان الشبكة مع الإصدار السادس من بروتوكول الإنترنت مادام ذلك ممكناً.[7]

على الجانت الآخر، تُقدِّم ترجمة عناوين الشبكة مجموعةً من المنافع والتسهيلات المرتبطة بمسائل العنونة في الإصدار الرابع من بروتوكول الإنترنت، ولكنَّها تصلح أيضاً عند العنونة بالإصدار السادس منه، ومنها على سبيل المثال تجنُّب عملية إعادة العنونة إذا انتقلت مؤسسة ما من موقع جغرافي إلى آخر، وعندها يمكن للمؤسسة أن تحافظ على نطاق العناوين القديم بوصفه نطاقاً داخليَّاً محليَّاً، ووتتصل مع العالم الخارجي بوصفه نطاقاً خارجيَّاً عبر عملية ترجمة عناوين الشبكة.[54] ومنها أيضاً مسألة المؤسسات مُتعدِدة الاستضافة، والتي تكون مواقع استضافتها مُتباعدة جغرافيَّاً لكنَّ المُضيفين فيها معنونون بفضاء العناوين ذاته، ويمكن في حالة كهذه، السماح للمضيفين بتبادل البيانات فيما بينهم باستعمال ترجمة العناوين المُضاعَفة دون الحاجة لإعادة العنونة.[54][55] ومنها أيضاً مسألة توحيد إعدادت التهيئة، فلو عُنونت الشبكات المحليَّة كلها باستعمال فضاء العناوين الخاصّ نفسه واتصلت مع العالم الخارجي عبر عملية ترجمة مُوحَّدة، لأمكن إعداد تهيئة مُوحدة تُستعمل في أي شبكة محليَّة مُعنونة بذلك الفضاء.[56]

على أيّ حال، طُوِّرت تقنية خاصة لترجمة عناوين الشبكة من أجل الإصدار السادس من بروتوكول الإنترنت، ووصفت في الوثيقة RFC 6296، ولكنّ العمل ظل في الإطار التجريبيّ ولم ينتقل إلى مرحلة المعيار الرسمي.[57][58]

بروتوكول التحكم بالنقل

بروتوكول التحكم بالنقل (بالإنجليزية: Transprot control Protocol اختصاراً TCP)‏ هو بروتوكول نقل يؤمن توصيلاً مؤثوقاً للبيانات عبر قنوات اتصال مهيأ.[59] تعمل آلية ترجمة العناوين على مراقبة محتويات ترويسة البروتوكول الموجودة داخل رزم البيانات المُتبادلة بين طرفي الاتصال من أجل تحديد بداية الجلسة.[60] وفقاً لبروتوكول التحكم بالنقل، يُنشَئ الاتصال بين طرفين بعد إنجاز عملية المصافحة الثلاثيّة، وهي تشمل تبادلاً لمعلومات ذات صلة بالاتصال، مثل رقم التتابع. يمكن تحديد حصول المصافحة الثلاثية من خلال تمييز نمط محدد لقيم علمين من أعلام البروتوكول موجودين في ترويسته داخل الرسائل المُتبادَلة بين الطرفين. وهذان العلمان هما علما المُزامنة SYN وإشعار التأكيد ACK.[61]

بشكلٍ مُشابه لما سبق، تراقب آلية الترجمة محتويات الترويسة لتحديد نهاية الجلسة، والتي يُمكن تحديدها إذا كانت بالتراضي من خلال مراقبة قيم علم النهاية FIN في ترويسة البروتوكول، أو من مراقبة قيمة علم إعادة الضبط RST في حال كان الإنهاء قسريَّاً ومباشراً.[62][63] تصف الوثيقة RFC 5382 المتطلبات السلوكية اللازمة لآلية ترجمة عنوان الشبكة من أجل العمل بشكل سليم مع بروتوكول التحكم بالنقل.[64]

تحدد الوثيقة السابقة أيضاً كيفية التعامل مع حالات "الاتصال المقطوع"، وهي الحالات التي يتوقف فيها الطرف الآخر عن المشاركة في الجلسة بدون إنهائها، أو تلك التي يتعذر فيها تحديد حالة الطرف الآخر، ويجب على المُوجِّه الذي يقوم بترجمة العناوين عندها أن يقوم بإنهاء الجلسة من تلقاء ذاته. تحدد الوثيقة زمناً للانتظار في حال غياب أي نشاط من الطرف الآخر وهو 4 دقائق بعد آخر نشاط إذا كان إنشاء الاتصال قد بدأ ولكنَّه لم يكتمل، وساعتان وأربع دقائق إذا كان الاتصال مُنشأً ونشيطاً.[65] بالإضافة لذلك، تتناول الوثيقة أيضاً كيفية التعامل مع حالة إنشاء الاتصال بين الأقران،[66] وهي حالة خاصَّة يحاول فيها طرفا الاتصال إنشاءَه في الوقت نفسه، ويكون التغيير في تتابع قيم الأعلام مُختلفاً عن النمط الموجود في المصافحة الثلاثيَّة.[67]

بروتوكول حزم بيانات المُستخدم

بروتوكول حزم بيانات المستخدم (بالإنجليزية: User Datagram protocol اختصاراً UDP)‏ هو بروتوكول نقل غير موثوق يُؤمِّن اتصالاً لنقل البيانات عبر قنوات غير مهيأة.[68] يدعم هذا البروتوكول عملية نقل البيانات بدون تأسيس اتصال، وهو لا يطلب إشعاراً لتأكيد استلام البيانات المُرسَلة، ولذلك تكون ترويسته أصغر حجماً.[69] نتيجةً لذلك، ليس هناك أعلام في الترويسة تساعد على تحديد بداية ونهاية الجلسة، فهي الجلسة عند وصول أول رزمة بيانات تُحدد محتوياتها اتصالاً جديداً، وتجري عملية الترجمة عليها بحسب التهيئة، ويُرفع علم بيان الحالة الخاص بزوج المُعرفات المستخدم للدلالة على حجزه لمدة زمنية، هي دقيقتين على الأقل (6)، وهي تُجدد آليَّاً كُلما استقبل المُوجِّه الذي يقوم بالترجمة رزمةً جديدةً من نفس الجلسة، فإذا انتهت المدة ولم تستقبل أي رزمة بعدُ، عدّ المُوجه أن الاتصال مقطوعٌ، وحرر زوج المُعرِّفات المُستخدم في الترجمة.[70]

هناك مشكلة مُرتبطة بعملية تقطيع رزم البيانات، فالقطع الناتجة، جميعها خلا الأولى، لا تحتوي ترويسة بروتوكول النقل، وبسبب ذلك، لا يُمكن إجراء عملية ترجمة أرقام المنافذ ما لم يتم إعادة تجميع الرزمة الأصليَّة كاملةً. في هذه الحالة، غالباً ما يجري التخلص من الرزمة بدون إجراء عملية الترجمة، وتحصل هذه المشكلة نفسها لو اُستخدم بروتوكول التحكم بالنقل أيضاً.[71]

بروتوكولات أخرى

هناك بروتوكولات نقل أخرى مستعملة في شبكات البيانات وهي أقل شيوعاً من البروتوكولين السابقين، منها مثلاً بروتوكول التحكم بازدحام الرزم [الإنجليزية] DCCP الموصُوف بوثيقة طلب التعليقات RFC 4340.[72] تصف الوثيقة 5597 RFC المتلطلبات السلوكية اللازمة لاستعمال ترجمة عناوين الشبكة مع هذا البروتوكول.[73] أمَّا بروتوكول التحكم بتدفق النقل SCTP فهو بروتوكول نقل طُوِّر أساساً لنقل رسائل التأشير الخاصة بشبكات الهاتف العامَّة عبر شبكة معنونة ببروتوكول الإنترنت، وله تطبيقاتٌ أخرى في مجال نقل الصوت عبر الإنترنت [74]، وهو موصوف بالوثيقة 4960 RFC.[75] ليس هناك وثيقة طلب تعليقات تصف المُتطلبات السلوكية لاستعمال ترجمة عناوين الشبكة معه، ولكن هناك مسودة لوثيقة صيغت في سنة 2009م، ولم يجرِ تبنيها لتصبح معياراً رسميَّاً.[76]

مشكلات في التطبيق
  • تقطيع رزم البيانات: إذا قطعت رزم البيانات، فإن ترويسة بروتوكول النقل ستكون في أول قطعة فقط، ويُسبب هذا إشكالات في مراقبة الجلسة إذا كان بروتوكول النقل هو بروتوكول التحكم بالنقل. بالإضافة لذلك، أيَّاً كان بروتوكول النقل المُستعمل، لا يمكن تنفيذ ترجمة أرقام المنافذ في حال التقطيع، فجميع القطع الناتجة، ما خلا القطعة الأولى لا تحتوي على أرقام المنافذ أصلاً بسبب غياب ترويسة بروتوكول النقل فيها، ولا يمكن إجراء ترجمة أرقام المنافذ عليها.[51]
  • الاستعمال مع بروتوكول نقل الملفات: يستعمل بروتوكول نقل الملفات أمري Port وPASV (7) في جلسة التحكم الخاصة بالحمولة من أجل تحديد عنوان بروتوكول الإنترنت ورقم المنفذ اللذان سوف يستعملان في جلسة نقل البيانات ويجري عملية نقلهما بعد ترميزهما بترمز آسكي.[77] وتحصل المشكلة عندما يتغير طول العنوان فمثلاً العنوان: 10.0.0.1 يُرمَّز بخمسة محارف آسكي، بينما يُرمَّز العنوان 200.100.10.1 بتسع محارف. وهذا التغيير في الطول إشكالاً في قيمة رقم التتابع في ترويسة بروتوكول التحكم بالنقل، ويجب، بعد إجراء الترجمة، تحديث هذه القيمة أيضاً لتعكس التغيير الحاصل في الترويسات في رزمة البيانات المُترجَمة.[78]
  • التطبيقات المعتمدة على المُعرِّفات المترجمة: هناك مجموعة من التطبيقات اللاتي يعتمد عملها على عنوان بروتوكول الإنترنت أو أرقام المنافذ أو تحتويهما في موقع ما من ترويستها. وبالتالي، فإنَّ تبديل هذا العنوان بعملية الترجمة يُسبب مشكلة في عمل التطبيق، ويجب إجراء عملية التبديل في ترويسة بروتوكول التطبيق أيضاً، وللقيام بذلك تُستخدم تطبيقات خاصَّة تُهيأ في المُوجِّه الذي يقوم بعملية الترجمة، وتسمَّى الواحدة منها البوابة على مستوى التطبيق (بالإنجليزية: Application level gateway اختصاراً ALG)‏.[8] طرح حل آخر لهذه المشكلة وهو تخطي الترجمة (بالإنجليزية: NAT Traversal)‏ ويشمل عمل تطبيق ما في المضيفين للحصول على مُعرِّفات الطرف الآخر البعيد الذي يراد الاتصال معه، ثم إجراء التبديل اللازم في ترويسة بروتوكول التطبيق في المُضيف الذي يُرسل الرزمة قبل إرسالها لتجري ترجمة العناوين فيها.[79] طُوِّرت مجموعة من البروتوكولات التي تتبنى هذا الحل أو شكلاً مُشتقَّاً عنه، أشهرها: بروتوكول خدمات تخطي جلسة ترجمة عنوان الشبكة [الإنجليزية] STUN وهو موصوف في الوثيقة RFC 5389،[80] وبروتوكول تخطي الترجمة باستعمال المُرحلات [الإنجليزية] TURN وهو موصوف في الوثيقة RFC 5766.[81]
  • الحاجة لإعادة الحساب: ترجمة عنوان الشبكة هي آلية تتطلب حوسبة وقدرات معالجة بكثافة، فمن أجل كل رزمة يجري ترجمتها، هناك حاجة لإعادة حساب كل تحقق جمعيّ يشمل ما جرى تعديله، وهذا يتطلب قدرات معالجة وقد يُسبب تأخيراً في عملية توجيه الرزمة.[82]

هوامش

1. العنوان الأصلي: (بالإنجليزية: IP Network Address Translator (NAT) Terminology and Considerations)‏.[30]

2. يُسمَّى هذا النطاق عدَّة أسماء أخرى أيضاً منها النطاق الخارجي (بالإنجليزية: Outside realm)‏ أو(بالإنجليزية: External realm)‏ والنطاق العام (بالإنجليزية: Public realm)‏ والنطاق العالمي (بالإنجليزية: Global realm)‏.

3. يُسمَّى هذا النطاق عدَّة أسماء أخرى أيضاً منها: النطاق الداخلي (بالإنجليزية: Inside realm)‏ والنطاق الخاص (بالإنجليزية: Private realm)‏ والنطاق المحلي (بالإنجليزية: Local realm)‏.

4. تُسمَّى أيضاً ترجمة عناوين الشبكة المتراكبة (بالإنجليزية: Overlapping NAT)‏، وهذا الاسم مأخوذ من أحد تطبيقات التقنية، وفيه يكون هناك مجالا عناوين متراكبان، أحدهما في النطاق الخارجي والآخر في النطاق الداخلي، وتسمح هذه التقنية لمضيفي هذه العناوين المتباعدَين بالتواصل مع بعضهما البعض وتبادل البيانات.[83]

5. هناك لغطٌ في التسمية الإنجليزية جرى تجاوزه عند تعريب المُصطلحات، فالأسماء المُستعملة في المراجع المُعتمدة لوصف هذه التقنية لا تتوافق مع الأسماء الموجودة في المعيار الرسمي، وفيها يُشار إلى النطاق الداخلي باستعمال كلمة Local، وللنطاق الخارجي باستعمال كلمة Global، بدلاً من Inside وOutside المُستعملة في المعيار، ولكن هاتين الكلمتين، أي Inside وOutside، تُستعملان لتحديد النطاق الذي يستخدم فيه العنوان، وبذلك تكون العناوين في المراجع كما يأتي:

وقد تُرجمت العناوين إلى العربية بتصرف للتوحيد مع المعيار الأصلي ولإزالة هذا اللبس.

6. قد تتنوع قيمة مؤقت الانتظار بشكلٍ كبير بحسب التطبيق الذي يُنفِّذ ترجمة عناوين الشبكة، ولكن التوصيات المعياريَّة توصي بألا تقل هذه المدة عن دقيقتين، وتُحبِّذ قيمة 5 دقائق لها.[70][84]

7. وهذا اختصار من كلمة غير فاعل (بالإنجليزية: Passive)‏، وهو أمرٌ لمخدم بروتوكول نقل الملفات للانتظار ومراقبة الأوامر الواردة بحثاً عن رقم منفذ مُحدد من أجل إنشاء الاتصال، عوضاً عن الوضع الافتراضي الذي تبدأ فيه عملية بإنشاء الاتصال بعد استقبال أمر النقل مباشرةً.[77]

انظر أيضًا

مراجع
فهرس المراجع
  1. Dictionary of Networking, P.264-265
  2. Egevang, K.; Francis, P. (مايو 1994). "RFC 1631, The IP Network Address Translator (NAT)" (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC1631. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 12 يناير 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  3. Network Protocols Handbook ؛P. 27
  4. Cisco CCENT/CCNA ICND1, P.581-585
  5. RFC 3022, P.7-8
  6. RFC 2663, P. 9-14
  7. B. Aboba, Ed.; E. Davies (يوليو 2007). "RFC 4924, Reflections on Internet Transparency". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC4924. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  8. RFC 2663, P.6
  9. TCP/IP Illustrated, P.310
  10. . The TCP/IP Guide, P.235-255
  11. Dictionary of Networking , P.199
  12. J. Postel (سبتمبر 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (باللغة الإنجليزية). صفحة 7. doi:10.17487/RFC0791. مؤرشف من الأصل في 12 فبراير 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  13. RFC 4632, P.3
  14. Ramesh Chandra (2003). Information Technology: A Revolutionary Change (باللغة الإنجليزية). Kalpaz publication. صفحة 80. ISBN 817835201X. الوسيط |CitationClass= تم تجاهله (مساعدة)
  15. RFC 4632, P.1
  16. S. Bradner; A. Mankin (يناير 1995). "RFC 1752, The Recommendation for the IP Next Generation Protocol". The Internet Society (باللغة الإنجليزية). صفحة 4. doi:10.17487/RFC1752. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 31 مارس 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  17. RFC 4632, P.4
  18. TCP/IP Illustrated, P.47
  19. V. Fuller; T. Li; J. Yu; K. Varadhan (سبتمبر 1993). "RFC 1338, Supernetting: an Address Assignment and Aggregation Strategy". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1338. مؤرشف من الأصل في 06 مارس 2020. اطلع عليه بتاريخ 12 يناير 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  20. RFC 1918, P.1
  21. S. Deering; R. Hinden (ديسمبر 1995). "RFC 1883, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 2019. اطلع عليه بتاريخ 14 يناير 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  22. "Free Pool of IPv4 Address Space Depleted". Number Resource Organization (باللغة الإنجليزية). 3 فبراير 2011. مؤرشف من الأصل في 5 مارس 2020. اطلع عليه بتاريخ 6 مارس 2019. الوسيط |CitationClass= تم تجاهله (مساعدة)
  23. Cisco CCENT/CCNA ICND1, P.581
  24. M. Cotton; L. Vegoda; R. Bonica, Ed.; B. Haberman (أبريل 2013). "RFC 6890, Special-Purpose IP Address Registries". The Internet Society (باللغة الإنجليزية). صفحة 6,8,11. doi:10.17487/RFC6890. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 31 مارس 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  25. RFC 1918, P.4
  26. Dictionary of Networking, P.305-306
  27. M. Cotton; L. Eggert; J. Touch; M. Westerlund; S. Cheshire (أغسطس 2011). "RFC 6335, Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". The Internet Society (باللغة الإنجليزية). صفحة 6. doi:10.17487/RFC6335. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 31 مارس 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  28. RFC 793, P.10
  29. "Service Name and Transport Protocol Port Number Registry". IANA (باللغة en Service Name and Transport Protocol Port Number Registry). مؤرشف من الأصل في 15 يوليو 2018. الوسيط |CitationClass= تم تجاهله (مساعدة); line feed character في |لغة= على وضع 3 (مساعدة)صيانة CS1: لغة غير مدعومة (link)
  30. RFC 2663, P.3
  31. TCP/IP Illustrated, P.304
  32. RFC 3022, P.9
  33. TCP/IP Illustrated, P.304-305
  34. RFC 2663, P.10
  35. RFC 2663, P.11
  36. Cisco CCENT/CCNA ICND1, P.582-585
  37. The TCP/IP Guide, P.530
  38. TCP/IP Illustrated, P.311-312
  39. Cisco CCENT/CCNA ICND1, P.583
  40. TCP/IP Illustrated, P.312
  41. Cisco CCENT/CCNA ICND1, P.584-585
  42. TCP/IP Illustrated, P.311
  43. Cisco CCENT/CCNA ICND1, P.585-587
  44. RFC 3022, P.8-9
  45. RFC 2663, P.12
  46. Cisco CCENT/CCNA ICND1, P.584
  47. The TCP/IP Guide , P.524
  48. RFC 2663, P.13
  49. Dictionary of Networking, P.190
  50. J. Postel (سبتمبر 1981). "RFC 792, INTERNET CONTROL MESSAGE PROTOCOL". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC0792. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 1 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  51. TCP/IP Illustrated, P.309
  52. P. Srisuresh; B. Ford; S. Sivakumar; S. Guha (أبريل 2009). "RFC 5508, NAT Behavioral Requirements for ICMP". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC5508. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  53. RFC 5902, P.1
  54. RFC 5902, P.3
  55. RFC 2663, P.11-12
  56. RFC 5902, P.4-5
  57. M. Wasserman; F. Baker (يونيو 2011). "RFC 6296, IPv6-to-IPv6 Network Prefix Translation". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC6296. ISSN 2070-1721. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  58. TCP/IP Illustrated, P.310-311
  59. Dictionary of Networking, P.386
  60. TCP/IP Illustrated, P.307
  61. RFC 793, P.27-28
  62. RFC 793, P.82
  63. The TCP/IP Guide, P.307
  64. RFC 5382, P.1
  65. RFC 5382, P.11
  66. P. Srisuresh; B. Ford; D. Kegel (مارس 2008). "RFC 5128, State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC5128. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  67. RFC 5382, P.6
  68. Dictionary of Networking, P.400
  69. J. Postel (أغسطس 1980). "RFC 768, User Datagram Protocol". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC0768. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  70. RFC 4787, P.12
  71. L. Eggert; G. Fairhurst; G. Shepherd (مارس 2017). "RFC 8085, UDP Usage Guidelines User Datagram Protocol". The Internet Society (باللغة الإنجليزية). صفحة 19. doi:10.17487/RFC8085. ISSN 2070-1721. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  72. E. Kohler; M. Handley; S. Floyd (مارس 2006). "RFC 4340, Datagram Congestion Control Protocol (DCCP)". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC4340. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  73. R. Denis-Courmont (سبتمبر 2009). "RFC 5597, Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC5597. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  74. Network Protocols Handbook, P.147
  75. R. Stewart, Ed. (سبتمبر 2007). "RFC 4960, Stream Control Transmission Protocol". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC4960. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  76. R. Stewart; M. Tuexen; I. Ruengeler (16 فبراير 2009). "Stream Control Transmission Protocol (SCTP) Network Address Translation draft-ietf-behave-sctpnat-01.txt". The Internet Society (باللغة الإنجليزية). صفحة 1. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  77. RFC 959, P.28
  78. RFC 2663, P.285
  79. TCP/IP Illustrated, P.316
  80. J. Rosenberg; R. Mahy; P. Matthews; D. Wing (أوكتوبر 2008). "RFC 5389, Session Traversal Utilities for NAT (STUN)". The Internet Society (باللغة الإنجليزية). صفحة 12. doi:10.17487/RFC5389. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة); تحقق من التاريخ في: |تاريخ= (مساعدة)
  81. R. Mahy; P. Matthews; J. Rosenberg (أبريل 2010). "RFC 5766, Traversal Using Relays around NAT (TURN):Relay Extensions to Session Traversal Utilities for NAT (STUN)". The Internet Society (باللغة الإنجليزية). صفحة 12. doi:10.17487/RFC5766. مؤرشف من الأصل في 02 أبريل 2020. اطلع عليه بتاريخ 2 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)
  82. RFC 2663, P.26
  83. The TCP/IP Guide, P.539
  84. The TCP/IP Guide, P.509
    المعلومات الكاملة للمراجع المُستشهد بها أكثر من مرة

    أولاً: الكتب: (مرتبة بحسب تاريخ النشر)

    • Peter Dyson; Kevin Shafer (1999). Dictionary of Networking (باللغة الإنجليزية) (الطبعة الثالثة). SYBEX Inc. ISBN 0782124615. الوسيط |CitationClass= تم تجاهله (مساعدة)
    • Charles M. Kozierok (2005). The TCP/IP Guide (PDF) (باللغة الإنجليزية). William Pollock. ISBN 1-59327-047-X. الوسيط |CitationClass= تم تجاهله (مساعدة)
    • Network Protocols Handbook (PDF) (باللغة الإنجليزية) (الطبعة الثانية). Javvin Technologies Inc. 2005. الوسيط |CitationClass= تم تجاهله (مساعدة)
    • Kevin R.Fall; W.Richard Stevens (2012). TCP/IP Illustrated Volume 1 (PDF) (باللغة الإنجليزية) (الطبعة الثانية). Pearson Education, Inc. ISBN 0321336313. الوسيط |CitationClass= تم تجاهله (مساعدة)
    • Wendell Odom (2013). Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide (باللغة الإنجليزية) (الطبعة الأكاديمية). Pearson Education, Inc. ISBN 1587144859. الوسيط |CitationClass= تم تجاهله (مساعدة)

    ثانياً: وثائق طلب التعليقات: (مرتبة بحسب رقم الوثيقة)

    وصلات خارحية
    • بوابة علم الحاسوب
    • بوابة تقنية المعلومات
    • بوابة اتصال عن بعد
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.