أساسيات الشبكات الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP

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

إنشاء الشبكات الفرعية Subnetting والعنونة عديمة التصنيف Classless Addressing

كان الهدف الأساسي من عناوين IP هو تحديد جزء الشبكة بصورة فريدة، وتحديدًا شبكةً فيزيائيةً واحدةً بالضبط. ولكن اتضح أنّ هذا النهج له بعض العيوب. فتخيّل أنّ حرمًا جامعيًا كبيرًا به الكثير من الشبكات الداخلية قرّر الاتصال بالإنترنت. هنا سيحتاج موقع كلّ شبكة مهما كانت صغيرة، إلى عنوان شبكة من الصنف C. والأسوأ من ذلك هو حاجة أية شبكة بها أكثر من 255 مضيفًا إلى عنوان من الصنف B. قد لا يبدو هذا أمرًا بالغ الأهمية، ولكن في الواقع لم يكن الأمر كذلك عندما حدث تصوّر الإنترنت لأول مرّة، فهناك عدد محدود فقط من أرقام الشبكات، وعدد أقل بكثير من عناوين الصنف B مقارنة بعناوين الصنف C. حيث تميل عناوين الصنف B إلى أن تكون ذات طلب مرتفع خاصةً لأنك لا تعرف أبدًا إذا كانت شبكتك ستتوسع إلى أكثر من 255 عقدة، لذلك فمن الأسهل استخدام عناوين الفئة B من البداية بدلًا من الاضطرار إلى إعادة ترقيم كلّ مضيف عند نفاد مساحة شبكة من الصنف C. لكن المشكلة التي نلاحظها هنا هي عدم كفاءة إسناد Assigning العناوين، إذ تستخدم الشبكة ذات العقدتين عناوين شبكة من الفئة C بالكامل، وبالتالي تُهدِر 253 عنوانًا مفيدًا، كما تُهدِر أيضًا شبكةٌ من الصنف B -تضم أكثر بقليل من 255 مضيفًا- أكثرَ من 64000 عنوان.

لذلك، إسناد رقم شبكة واحد لكلّ شبكة فيزيائية يستهلك حيز عناوين IP، حيث يُحتمل أنّ يكون هذا الاستهلاك أسرع بكثير مما نودّ. وسنحتاج إلى توصيل أكثر من 4 مليارات مضيف لاستخدام جميع العناوين الصالحة، كما سنحتاج فقط إلى توصيل 214 (حوالي 16000) شبكة من الصنف B قبل نفاد هذا الجزء من حيز العناوين، لذلك لابد إيجاد طريقة ما لاستخدام أرقام الشبكة بصورة أكثر كفاءة.

يؤدّي إسناد Assigning العديد من أرقام الشبكة إلى عيبٍ آخر يتضّح عندما تفكِّر في التوجيه routing. تذكّر أنّ مقدار الحالة المخزَّنة في عقدةٍ مشاركة في بروتوكول التوجيه متناسبٌ مع عدد العقد الأخرى. وأنّ التوجيه في الإنترنت internet يتكون من بناء جداول التمرير التي تخبر الموجّه بكيفية الوصول إلى شبكات مختلفة. وبالتالي كلّما زاد عدد أرقام الشبكة المستخدَمة، زاد حجم جداول إعادة التوجيه forwarding tables. كما تزيد جداول التمرير الكبيرة التكاليف على الموجِّهات، ومن المحتمل بطؤها في البحث مقارنة مع الجداول الأصغر لتقنية معيّنة. لذا فهي تقلل من أداء الموجّه، ويوفر هذا دافعًا آخر لإسناد أرقام الشبكة بعناية.

يوفّر إنشاء الشبكات الفرعية Subnetting الخطوة الأولى لتقليل العدد الإجمالي لأرقام الشبكة المسنَدة. تكمن الفكرة في أخذ رقم شبكة IP واحد وتخصيص عناوين IP مع رقم الشبكة هذا للعديد من الشبكات الفيزيائية، والتي يشار إليها الآن باسم الشبكات الفرعية subnets. هناك العديد من الأشياء الواجب القيام بها لإنجاح هذا العمل. إذ يجب أولًا أن تكون الشبكات الفرعية قريبةً من بعضها البعض، لأنها ستبدو جميعها مثل شبكة واحدة إذا نظرت إليها من نقطة بعيدة في الإنترنت. كما لا بد من وجود رقم شبكة واحد فقط بينها. وهذا يعني أن الموجّه سيكون قادرًا فقط على تحديد مسار واحد للوصول إلى أيٍّ من الشبكات الفرعية، لذلك فمن الأفضل أن تكون جميعها في نفس الاتجاه العام.

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

تتضمّن الآلية التي يمكن من خلالها تشارُك رقمِ شبكة واحد بين شبكات متعدِّدة، ضبطَ جميع العقد في كلّ شبكة فرعية باستخدام قناع الشبكة الفرعية subnet mask. إذ يجب أن يكون لجميع المضيفين على نفس الشبكة رقم الشبكة نفسه باستخدام نفس تنسيق عناوين IP البسيط. ويتيح لنا قناع الشبكة الفرعية تقديم رقم شبكة فرعية، بحيث سيكون لجميع المضيفين على نفس الشبكة الفيزيائية نفس رقم الشبكة الفرعية، مما يعني أنّ المضيفين قد يكونوا على شبكات فيزيائية مختلفة لكنهم يشتركون برقم شبكة واحد. هذا المفهوم موضَّح في الشكل التالي:

ضُبِط المضيف الآن باستخدام كلٍّ من عنوان IP وقناع الشبكة الفرعية المرفقة به. حيث ضُبِط المضيف H1 في الشكل الآتي مثلًا بعنوان 128.96.34.15 وقناع شبكة فرعية 255.255.255.128. تُضبَط جميع الأجهزة المضيفة على شبكةٍ فرعية معيَّنة بنفس القناع؛ أي يوجد قناع شبكة فرعية واحد لكلّ شبكة فرعية. وتحدّد العملية الثنائية AND لهذين الرقمين رقمَ الشبكة الفرعية للمضيف ولجميع الأجهزة المضيفة الأخرى على نفس الشبكة الفرعية. ويُعَدّ 128.96.34.15 AND 255.255.255.128 في هذه الحالة مساويًا ،128.96.34.0 وهذا هو رقم الشبكة الفرعية العلوية في الشكل التالي:

أول شيء يفعله المضيف عند إرسال رزمة إلى عنوان IP معيّن هو إجراء العملية الثنائية AND بين قناع الشبكة الفرعية الخاصة به وعنوان IP الوجهة. فإذا كانت النتيجة مساويةً لرقم شبكة المضيف المرسَل الفرعية، فسيعرف أنّ المضيف الوجهة موجود على نفس الشبكة الفرعية، ويمكن تسليم الرزمة مباشرةً عبر الشبكة الفرعية. أما إذا كانت النتائج غير متساوية، فيجب إرسال الرزمة إلى موجّهٍ لتمريرها إلى شبكة فرعية أخرى. لو أرسل المضيف H1 إلى H2 مثلًا، سيطبّق المضيف H1 عملية AND على قناع شبكته الفرعية (255.255.255.128) مع عنوان المضيف H2 وهو (128.96.34.139) فينتج العنوان 128.96.34.128. لا تتطابق هذه النتيجة مع رقم شبكة المضيف H1 الفرعية (128.96.34.0)، لذلك يعرف المضيف H1 أنّ المضيف H2 موجود على شبكة فرعية مختلفة. فيرسل المضيف H1 الرزمة إلى الموجّه الافتراضي الخاص به R1، نظرًا لعدم قدرة المضيف H1 على تسليم الرزمة إلى المضيف H2 مباشرةً عبر الشبكة الفرعية.

يتغير جدول التمرير الخاص بالموجّه أيضًا بصورة طفيفة عند استخدام الشبكات الفرعية. تذكّر أنه كان لدينا سابقًا جدول تمرير مكوَّنٌ من مدخلات من النموذج NetworkNum ، NextHop. ويجب أن يحتوي الآن على مدخلات من النموذج SubnetNumber ، SubnetMask ، NextHop لدعم الشبكات الفرعية. كما يطبّق الموجّه عملية AND على عنوان وجهة الرزمة مع قناع الشبكة الفرعية SubnetMask لكل مدخَلةٍ للعثور على المدخَلة الصحيحة في الجدول. فإذا تطابقت النتيجة مع رقم الشبكة الفرعية SubnetNumber للمدخَلة فهذه هي المدخلة الصحيحة التي يجب استخدامها، ويمرر الرزمة إلى موجّه القفزة التالي المشار إليه. كما سيكون للموجّه R1 في مثال الشبكة ضمن الشكل السابق المدخلات الموضّحة في الجدول التالي:

نستمر في مثال مخطَط البيانات المرسَل من المضيف H1 إلى المضيف H2، حيث سيجري الموجّه R1 عملية AND على عنوان المضيف H2 الذي هو (128.96.34.139) مع قناع الشبكة الفرعية للمدخَلة الأولى (255.255.255.128)، ويوازن النتيجة (128.96.34.128) مع رقم شبكة هذه المدخلة (128.96.34.0). وبما أنهما ليسا متطابقين، فسينتقل إلى المدخَلة التالية، إلى أن تحدث المطابقة. لذا يسلّم الموجه R1 مخطط البيانات إلى المضيف H2 باستخدام الواجهة 1، وهي الواجهة المتصلة بنفس شبكة المضيف H2.

يمكن الآن وصف خوارزمية إعادة توجيه مخطَّط البيانات بالطريقة التالية:

D = الوجهة IP عنوان
for each forwarding table entry (SubnetNumber, SubnetMask, NextHop)
    D1 = SubnetMask & D
    if D1 = SubnetNumber
        if NextHop is an interface (واجهة)
            سلّم مخطط البيانات مباشرةً إلى الوجهة 
        else
            سلّم مخطط البيانات إلى العقدة التوجيهية التالية أو إلى الموجّه 

يُضمَّن عادةً مسار التوجيه الافتراضي default route في الجدول على الرغم من عدم ظهوره في هذا المثال، ويمكن استخدامه إذا لم يُعثَر على مطابقات صريحة. لاحظ أنّ تطبيقًا ساذجًا لهذه الخوارزمية سيكون غير فعال نهائيًا، وهو تطبيق يتضمّن عملية AND متكرِّرة على عنوان الوجهة، مع قناع شبكة فرعية وقد لا تكون هذه العملية مختلفةً في كلّ مرّة، إلى جانب البحث الخطي في الجدول.

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

العنونة عديمة التصنيف Classless Addressing

للشبكات الفرعية نظير، يُطلق عليه أحيانًا اسم إعداد مجموعة شبكات فرعية متجاورة supernetting، ولكن غالبًا ما يُطلق عليه التوجيه عديم التصنيف بين النطاقات Classless Interdomain Routing أو اختصارًا CIDR، وتُلفَظ "cider". يأخذ نظام CIDR فكرة الشبكات الفرعية إلى نهايتها المنطقية من خلال التخلص بشكل أساسي من أصناف العناوين.

لماذا لا تكفي الشبكات الفرعية subnetting وحدها؟ تسمح الشبكات الفرعية فقط بتقسيم العنوان ذي الصنف إلى شبكات فرعية متعدِّدة، بينما يسمح نظام CIDR بدمج العديد من العناوين ذات الصنف في مجموعة شبكات فرعية متجاورة supernet واحدة. كما يعالج أيضًا عدم كفاءة حيز العناوين، ويعمل بطريقة تحافظ على نظام التوجيه من التحميل الزائد overloaded.

افترض حالة الشركة الافتراضية التي تحتوي شبكتها على 256 مضيفًا، لمعرفة كيفية اقتران قضايا كفاءة حيّز العناوين مع قابلية توسّع نظام التوجيه. يُعَدّ الصنف C خيارًا غير مناسب بالنسبة للعدد المطلوب تغطيته من المضيفين، لذلك فقد تميل إلى استخدام الصنف B. ولكن استخدام قطعةٍ من حيز عناوينٍ قد يستخدم 65535 عنوان لعنوَنة 256 مضيفًا له كفاءة 256 / 65,535 = 0.39% فقط. وبالرغم من إمكانية مساعدة الشبكات الفرعية على إسناد العناوين بعناية، إلا أنها لا تتغلّب على حقيقة رغبة أية مؤسَّسة لديها أكثر من 255 مضيفًا أو توقعًا بوجود هذا العدد الكبير، بعناوين من الفئة B.

الطريقة الأولى التي قد تتعامل بها مع هذه المشكلة هي رفض إعطاء عنوان من الصنف B لأيّ مؤسسة تطلب ذلك ما لم يكن بإمكانها إظهار الحاجة إلى شيء قريب من 64 ألف عنوان، ومنحها بدلًا من ذلك عددًا مناسبًا من عناوين الصنف C لتغطية العدد المتوقَّع من المضيفين. إذ يمكن بصورةٍ أدق مطابقة مقدار حيّز العناوين المستهلكة مع حجم المؤسسة نظرًا لتوزيعنا لها الآن في قطعٍ chunks مؤلَّفة من 256 عنوانًا في المرّة الواحدة. ويمكن ضمان استخدامية عناوين بنسبة 50% على الأقل بالنسبة لأية مؤسسة بها 256 مضيفًا على الأقل، وعادةً أكثر من ذلك بكثير. وللأسف حتى وإن استطاعت الشركة تبرير استخدامها لعناوين من الصنف B، لن يُنظر لهذا الطلب كون عناوين الصنف B محجوزة منذ فترة طويلة.

لكنّ هذا الحلّ يثير مشكلةً خطيرة ألا وهي متطلبات التخزين الزائدة في الموجّهات. إذا كان هناك موقع واحد يحتوي على سبيل المثال على 16 رقم شبكة من الصنف C مُسندةً إليه، فهذا يعني أنّ كلّ موجّه إنترنت أساسي سيحتاج إلى 16 مدخلة في جداول التوجيه الخاصة به لتوجيه الرزم إلى هذا الموقع، حتى لو كان المسار إلى كلّ واحدة من هذه الشبكات هو نفسه. وإذا أُسندت عناوينًا من الصنف B للموقع، يمكن تخزين معلومات التوجيه نفسها في مدخَلة جدول واحدة، ولكن ستكون كفاءة إسناد العناوين فقط 16 × 255 / 65.536 = 6.2%.

لذلك يحاول نظام CIDR موازنة الرغبة في تقليل عدد المسارات التي يحتاج الموجّه إلى معرفتها مقابل الحاجة إلى توزيع العناوين بكفاءة. وللقيام بذلك، يساعدنا نظام CIDR في تجميع المسارات aggregate routes. حيث يُتيح لنا استخدام مدخَلةٍ في جدول التمرير تُخبرنا بكيفية الوصول إلى الكثير من الشبكات المختلفة، ويُتمّ ذلك عن طريق كسر الحدود الصارمة بين أصناف العناوين.

بفرض لدينا مؤسَّسة مكوّنة من 16 رقم شبكة من الصنف C، حيث يمكن توزيع مجموعة من عناوين الصنف C المتجاورة contiguous بدلًا من توزيع 16 عنوانًا عشوائيًا. وعلى فرض تم إسناد أرقام شبكة من الصنف C من 192.4.16 إلى 192.4.31. نلاحظ أنّ أعلى 20 بت لجميع العناوين في هذا النطاق هي نفسها (11000000 00000100 0001). وبالتالي فما أُنشئ بفعالية هو رقم شبكة مكوَّن من 20 بت، وهو شيء يقع بين رقم شبكة من الصنف B ورقم من الصنف C من حيث عدد الأجهزة المضيفة التي يمكنه دعمها. بمعنى ستحصل على كفاءة عنوَنة مرتفعة من خلال توزيع العناوين في قطعٍ أصغر من شبكةٍ من الصنف B، باستخدام بادئة prefix لشبكة واحدة يمكن استخدامها في جداول التمرير. لاحظ أنه لكي يعمل هذا المخطط، ستحتاج إلى توزيع كتلٍ blocks من عناوين الصنف C التي تشترك ببادئة مشتركة، مما يعني أنّ كلّ كتلة يجب أن تحتوي على عددٍ من شبكات الصنف C التي تكون من قوة العدد اثنين.

يتطلب نظام CIDR نوعًا جديدًا من الترميز لتمثيل أرقام الشبكة أو البادئات كما هي معروفة، لأنّ البادئات قد تكون بأيّ طول. والاصطلاح هو وضع / X بعد البادئة، حيث X هو طول البادئة بالبِتَات. لذلك يمكن تمثيل بادئة مؤلَّفة من 20 بتًا لجميع الشبكات من 192.4.16 إلى 192.4.31 على أنّها 192.4.16/20. أمّا إذا أردت تمثيل رقم شبكة واحد من الصنف C، يبلغ طوله 24 بتًا، فستكتبه .192.4.16/24

ستسمع الناس اليوم غالبًا يتحدثون عن بادئات "slash 24" أكثر من استخدام شبكات الصنف C، على الرغم من كون نظام CIDR هو المعيار الأساسي. ويمكن ملاحظة أنّ تمثيل عنوان الشبكة بهذه الطريقة مشابه لطريقة mask, value المُستخدمة في الشبكات الفرعية، طالما أنّ masks تتكوّن من بتات متجاورة تبدأ من البِت الأعلى أهميةً (وهو ما يحدث دائمًا في الواقع تقريبًا).

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

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

إعادة النظر في تمرير IP

افترضنا في كامل مناقشتنا لتمرير IP حتى الآن، قدرتنا على العثور على رقم الشبكة في الرزمة، ثم البحث عن هذا الرقم في جدول التمرير. ولكن نحتاج إلى إعادة فحص هذا الافتراض بعد تقديمنا لنظام CIDR. إذ يعني نظام CIDR أنّ البادئات قد تكون بأيّ طول من 2 إلى 32 بت. كما يمكن في بعض الأحيان علاوةً على ذلك، وجود تداخل overlap بين البادئات في جدول التمرير. أي أنّ بعض العناوين قد تتطابق مع أكثر من بادئة واحدة، فقد نجد مثلًا كلًا من البادِئَتين 171.69 (بادئة ذات 16 بت) و171.69.10 (بادئة ذات 24 بت) في جدول التمرير الخاص بموجّه واحد. حيث تتطابق في هذه الحالة الرزمة المخصصة للعنوان 171.69.10.5 على سبيل المثال، بوضوحٍ مع البادِئَتين. وتستند القاعدة في هذه الحالة على مبدأ أطول تطابُق longest match، أي أنّ الرزمة تطابِق البادئة الأطول، والتي ستكون 171.69.10 في هذا المثال. من ناحية أخرى، فالرزمة المخصَّصة للعنوان 171.69.20.5 ستطابِق البادئة 171.69 ولن تطابق البادئة 171.69.10، حيث ستكون البادئة 171.69 هي أطول تطابق في حالة عدم وجود أيّ مدخلة مطابقة أخرى في جدول التوجيه.

كانت مهمة العثور على أطول تطابق بكفاءة بين عناوين IP والبادئات متغيّرة الطول في جدول التمرير مجالًا مثمرًا للبحث لسنوات عديدة، إذ تَستخدم الخوارزمية الأكثر شهرة أسلوبًا يُعرف باسم شجرة PATRICIA، والذي طُوِّر بالفعل قبل نظام CIDR.

ترجمة العناوين باستخدام بروتوكول ARP

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

تتمثل إحدى الطرق البسيطة لربط عنوان IP مع عنوان شبكة فيزيائي في تشفير عنوان المضيف الفيزيائي في جزء المضيف من عنوان IP الخاصّ به. فقد يُمنَح مضيفٌ بعنوان فيزيائي 00100001 01001001 (الذي يحتوي على القيمة العشرية 33 في البايت العلوي و81 في البايت السفلي)، على أنّ عنوان IP هو 128.96.33.81. يُستخدَم هذا الحلّ في بعض الشبكات، غير أنّه محدود لأنّ عناوين الشبكة الفيزيائية لا يمكن أن تزيد عن 16 بتًا في هذا المثال، ويبلغ طولها 8 بتات فقط على شبكة من الصنف C. ومن الواضح أنّ هذا لن يعمل مع عناوين إيثرنت ذات 48 بتًا.

الحلّ الأعمّ هو احتفاظ كلّ مضيف بجدولٍ مؤلَّفٍ من أزواج عناوين، أي أنّ الجدول سيربط عناوين IP مع عناوين فيزيائية. كما قد يدير مسؤول النظام هذا الجدول مركزيًا ثمّ ينسخه إلى كلّ مضيف على الشبكة، إلا أنّ الأسلوب الأفضل هو تعلُّم كلّ مضيف محتويات الجدول ديناميكيًا باستخدام الشبكة. ويمكن تحقيق ذلك باستخدام بروتوكول تحليل العناوين Address Resolution Protocol أو اختصارًا ARP. فالهدف من بروتوكول ARP هو تمكين كلّ مضيف على الشبكة من إنشاء جدول روابط mappings بين عناوين IP وعناوين مستوى الرابط. وبما أنّ هذه الروابط mappings قد تتغير بمرور الوقت (لأن بطاقة إيثرنت في مضيف قد تنكسر وتُستبدَل ببطاقةٍ جديدة بعنوان جديد على سبيل المثال)، فتُعطَى المدخلات مهلةً دوريًا ثم تُزال. ويحدث هذا كلّ 15 دقيقة، بحيث تُعرَف مجموعة الروابط المُخزَّنة حاليًا في مضيف باسم ذاكرة ARP المخبئية cache أو جدول ARP.

يستفيد بروتوكول ARP من حقيقة دعم العديد من تقنيات الشبكة على مستوى الرابط مثل تقنية إيثرنت، للبثّ الإذاعي (broadcast. فإذا أراد المضيف إرسال مخطَّط بيانات IP إلى مضيفٍ (أو موجّه) يعرف وجوده على نفس الشبكة (أي أنّ عُقَد الإرسال والاستقبال لهما نفس رقم شبكة IP، فسيتحقق أولًا من الربط mapping في الذاكرة المخبئية. وإن لم يعثر على ذلك الربط، فسيحتاج المضيف إلى استدعاء بروتوكول ARP عبر الشبكة. وذلك عن طريق بث استعلام ARP إذاعي على الشبكة. يحتوي هذا الاستعلام على عنوان IP المَعنيّ (أي عنوان IP الهدف). حيث يتلقّى كل مضيف هذا الاستعلام، ويتحقق منه لمعرفة إذا كان مطابقًا لعنوان IP الخاص به. إذا حدث تطابق، فسيرسِل المضيف رسالة استجابة تحتوي على عنوان طبقة الربط الخاصة به مرةً أخرى إلى مُنشئ الاستعلام. كما يضيف منشئ الاستعلام المعلوماتِ الواردة في هذه الاستجابة إلى جدول ARP الخاص به.

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

يوضِّح الشكل السابق صيغة رزمة ARP لروابط mappings عناوين IP وعناوين إيثرنت. ويمكن استخدام بروتوكول ARP مع عدة أنواع أخرى من الروابط mappings، حيث أنّ الاختلافات الرئيسية هي في أحجام العناوين. تحتوي الرزمة بالإضافة إلى عنوان IP وعنوان طبقة الربط لكلٍّ من المرسل والهدف على ما يلي:

• حقل HardwareType الذي يحدِّد نوع الشبكة الفيزيائية (مثل شبكة إيثرنت).
• حقل ProtocolType الذي يحدِّد بروتوكول الطبقة العليا (مثل بروتوكول IP).
• حقل HLen (طول عنوان العتاد hardware address length) وحقل PLen (طول عنوان البروتوكول protocol address length) اللذان يحدِّدان طول عنوان طبقة الربط وعنوان بروتوكول الطبقة الأعلى على التوالي.
• حقل Operation الذي يحدِّد ما إذا كان هذا طلبًا أم استجابة.
• عنوان عتاد المصدر والهدف (إيثرنت مثلًا) وعنوان البروتوكول (IP مثلًا).

لاحظ إمكانية إضافة نتائج عملية ARP كعمود إضافي في جدول التمرير كما هو موضح بالجدول السابق. وبذلك لا يكتشف الموجّه R2 أنّ العقدة التوجيهية التالية هي الموجّه R1 فقط عندما يحتاج لتمرير رزمة إلى الشبكة 2 مثلًا، ولكنه يجد أيضًا عنوان MAC لوضعه على الرزمة لإرساله إلى الموجّه R1.

اقتباس

لقد رأينا الآن الآليات الأساسية التي يوفِّرها بروتوكول IP للتعامل مع كلٍّ من عدم التجانس والتوسّع. وفيما يتعلّق بمسألة عدم التجانس heterogeneity، فسيبدأ بروتوكول الإنترنت IP بتحديد نموذج خدمة أفضل جهد best-effort service model، بحيث يضع افتراضات قليلة حول الشبكات الأساسية underlying networks. والجدير بالذكر أنّ نموذج الخدمة هذا يعتمد على مخطَّطات بيانات غير موثوقة. كما يُضيف بروتوكول IP بعد ذلك إضافَتين مُهِمَتين إلى نقطة البداية هذه، وهما:

1. صيغة رزمة مشتركة ("التجزئة / إعادة التجميع" وهي الآلية التي تجعل هذه الصيغة تعمل عبر الشبكات مع MTU مختلفة).
2. حيز عنوَنة عام لتحديد جميع المضيفين ARP وهي الآلية التي تجعل حيِّز العنوَنة العام يعمل عبر شبكات ذات مخطّطات عنوَنة فيزيائية مختلفة). أمّا فيما يتعلق بمسألة التوسّع scale، فسيستخدم بروتوكول IP التجميع الهرمي hierarchical aggregation لتقليل كميّة المعلومات اللازمة لتمرير الرزم، حيث تُقسَّم عناوين IP إلى مكوِّنات للشبكة ومكوِّنات للمضيف، مع توجيه الرُّزم أولًا نحو الشبكة الوجهة ثم تسليمها إلى المضيف الصحيح على تلك الشبكة.

ضبط المضيف Host Configuration باستخدام بروتوكول DHCP

تضبط الشركةُ المصنّعة عناوين إيثرنت في محوّل adaptor الشبكة، وتُدار هذه العملية بطريقة تضمن تفرُّد هذه العناوين عالميًا. ومن الواضح أنّ هذا يُعَدّ شرطًا كافيًا لضمان أنّ أيّ مجموعة من الأجهزة المضيفة المتصِّلة بشبكة إيثرنت واحدة (بما في ذلك شبكة محلية ممتدة) سيكون لها عناوين فريدة. فكلّ ما نطلبه من عناوين إيثرنت هو التفرُّد uniqueness، ومع ذلك فلا يجب أن تكون عناوين IP فريدةً على شبكة متشابكة فحسب، بل لابدّ من عكسها أيضًا لمعمارية هذه الشبكة.

تحتوي عناوين IP على جزء الشبكة وجزء المضيف، ويجب أن يكون جزء الشبكة هو نفسه لجميع المضيفين على الشبكة نفسها. وبالتالي لا يمكن ضبط عنوان IP لمرّةٍ واحدة في مضيف عند تصنيعه، لأنّ ذلك يعني إعلام الشركة المصنّعة للشبكات التي سيتواجد فيها هؤلاء المضيفون. وهذا يعني عدم قدرة المضيف على الانتقال إلى شبكة أخرى بمجرّد اتصاله بشبكة معيّنة، ولذلك يجب أن تكون عناوين IP قابلةً لإعادة الضبط reconfigurable.

هناك بعض المعلومات الأخرى التي يحتاجها المضيف قبل تمكّنه من بدء إرسال الرزم إلى جانب عنوان IP. وأبرزها هي عنوان الموجّه الافتراضي، وهو المكان الذي قد يرسل المضيف إليه الرزم التي لا يكون عنوان وجهتها على نفس شبكة المضيف المرسل.

توفِّر معظم أنظمة تشغيل المضيف طريقةً لمسؤول النظام أو حتى لمستخدم النظام، لضبط configure معلومات IP التي يحتاجها المضيف يدويًا. ولكن هناك بعض العيوب الواضحة لمثل هذا الضبط اليدوي، وأحدها هو حاجته ببساطة للكثير من العمل لضبط جميع المضيفين في شبكة كبيرة، خاصةً عندما تفكّر في أنّ مثل هذه الأجهزة المضيفة لا يمكن الوصول إليها عبر الشبكة إلى حين ضبطها. والأهم من ذلك هو أنّ عملية الضبط معرضةٌ جدًا للخطأ، إذ من الضروري التأكد من حصول كلّ مضيف على رقم الشبكة الصحيح وعدم تلقّي أيّ مضيفَين لنفس عنوان IP. ولذلك يجب استخدام طرق الضبط الآلي automated configuration. تستخدم الطريقة الأساسية بروتوكولًا يُعرف باسم بروتوكول ضبط المضيف ديناميكيًا Dynamic Host Configuration Protocol أو اختصارًا DHCP.

يعتمد بروتوكول DHCP على وجود خادم DHCP مسؤول عن توفير معلومات ضبط المضيفين. حيث يوجد خادم DHCP واحد على الأقل لكل نطاقٍ إداري administrative domain. ويمكن لخادم DHCP أن يعمل بأبسط مستوى كمستودعٍ مركزي لمعلومات ضبط المضيف.

افترض مثلًا وجود مشكلة إدارة العناوين في الشبكة المتشابكة لشركة كبيرة. حيث يحمي بروتوكول DHCP مسؤولي الشبكة من الاضطرار للتجول إلى كلّ مضيفٍ في الشركة حاملين معهم قائمةً بالعناوين وخريطة الشبكة لضبط كلّ مضيفٍ يدويًا. وبدلًا من ذلك يمكن تخزين معلومات ضبط كلّ مضيف في خادم DHCP واستردادها تلقائيًا بواسطة كلّ مضيف عند تشغيله أو توصيله بالشبكة. ولكن سيبقى على مسؤول الشبكة اختيار العنوان الذي سيتلقّاه كلّ مضيف، حيث سيخزّن ذلك في الخادم فقط. وتُخزَّن معلومات ضبط كلّ مضيف في هذا النموذج ضمن جدولٍ مفهرسٍ بشكل من أشكال معرّف العميل الفريد، والذي عادةً ما يكون عنوان العتاد (عنوان الإيثرنت لمحوّل الشبكة الخاص به مثلًا).

يحمي الاستخدام الأعقد لبروتوكول DHCP مسؤول الشبكة حتى من الاضطرار إلى إسناد عناوين لكلّ مضيفٍ. حيث يحتفظ خادم DHCP في هذا النموذج بتجمُّعٍ pool من العناوين المتاحة التي يوزِّعها على المضيفين عند الطلب. وهذا يقلٍّل بصورة كبيرة من مقدار الضبط الواجب على مسؤول الشبكة القيام به. فمن الضروري الآن تخصيص نطاق من عناوين IP (جميعها بنفس رقم الشبكة) لكلّ شبكة. كما يُفضَّل إلغاء الغرض الأساسي من بروتوكول DHCP الذي هو تقليل لمقدار الضبط اليدوي المطلوب ليعمل المضيف، إذا توجب ضبط كلّ مضيف بعنوان خادم DHCP. وبالتالي فالمشكلة الأولى التي يواجهها بروتوكول DHCP هي اكتشاف الخادم.

يرسِل مضيفٌ مُشغَّلٌ أو متصلٌ حديثًا بالشبكة رسالةً DHCPDISCOVER إلى عنوان IP خاص (255.255.255.255)، وهو عنوان بث IP الإذاعي للاتصال بخادم DHCP. وهذا يعني استلام هذه الرسالة من قبل المضيفين والموجّهات على تلك الشبكة، ولا تعيد الموجّهات تمرير مثل هذه الرزم إلى شبكات أخرى، وهو ما يمنع البث الإذاعي إلى كامل شبكة الإنترنت. تكون إحدى هذه العقد هي خادم DHCP للشبكة في أبسط الحالات. وبالتالي سيجيب الخادم على المضيف الذي أنشأ رسالة الاكتشاف discovery message، لتَتجاهل جميع العٌقد الأخرى هذه الرسالة. لكن من غير المستحسن طلب خادم DHCP واحد على كلّ شبكة، لأنّ هذا مازال يؤدّي إلى إنشاء عدد كبير من الخوادم الواجب ضبطها بصورة صحيحة ومستقرّة. وبالتالي يستخدم بروتوكول DHCP مفهوم وكيل النقل relay agent. حيث يوجد وكيل نقلٍ واحد على الأقل في كل شبكة، ويُضبَط باستخدام معلومة واحدة فقط هي عنوان IP لخادم DHCP. وإذا تلقّى وكيل النقل رسالة DHCPDISCOVER، فسيُرسلها إلى خادم DHCP وينتظر الاستجابة، ثم يرسلها مرةً أخرى إلى العميل الطالب. يوضح الشكل التالي عملية نقل رسالة من مضيف إلى خادم DHCP بعيد:

يوضِّح الشكل الآتي صيغة رسالة DHCP. حيث تُرسَل الرسالة فعليًّا باستخدام بروتوكول يسمّى بروتوكول مخطط بيانات المستخدِم User Datagram Protocol أو اختصارًا UDP، والذي يعمل عبر بروتوكول IP. سنشرح بروتوكول UDP بالتفصيل لاحقًا. ولكن الشيء الوحيد المثير للاهتمام في هذا السياق هو توفير مفتاح فكّ الإرسال المتعدد الذي يقول "هذه رزمة DHCP".

إن بروتوكول DHCP مشتقٌ من بروتوكولٍ سابق يسمى BOOTP. وبالتالي فبعض حقول الرزم ليست ذات صلة وثيقة بضبط المضيف. حيث يضع العميل عنوان العتاد (عنوان الإيثرنت الخاص به على سبيل المثال) في حقل chaddr عند محاولة الحصول على معلومات الضبط. ليجيب خادم DHCP عن طريق ملء حقل yiaddr -أي عنوان IP الخاص بك your IP address-، وإرساله إلى العميل. ويمكن تضمين معلوماتٍ أخرى مثل الموجه الافتراضي الذي سيستخدمه هذا العميل في حقل الخيارات options.

من الواضح عدم قدرة المضيفين على الاحتفاظ بالعناوين إلى أجلٍ غير مسمى عندما يسند بروتوكول DHCP عناوين IP ديناميكيًا للمضيفين. إذ سيؤدّي هذا في النهاية إلى نفاذ تجمّع العناوين الخاص بالخادم. لذلك لا يمكن الاعتماد على مضيفٍ لإعادة عنوانه، لأنه قد يكون معطّلًا، أو مفصولًا عن الشبكة، أو قد توقّف تشغيله. بالتالي يسمح بروتوكول DHCP بتأجير العناوين لبعض الوقت، حيث يكون الخادم حرًا في إعادة هذا العنوان إلى مجموعة العناوين الخاصة به بمجرّد انتهاء وقت التأجير. ومن الواضح أنّ المضيف الذي يحمل عنوانًا مؤجّرًا، سيَحتاج إلى تجديد الإيجار دوريًا إذا كان لا يزال متصلًا بالشبكة ويعمل بصورة صحيحة.

اقتباس

يوضّح بروتوكول DHCP جانبًا مهمًا من جوانب التوسّع، وهو توسّع إدارة الشبكة. وبما أنّ مناقشات التوسع غالبًا ما تركّز على الحفاظ على حالة أجهزة الشبكة من الزيادة بسرعة كبيرة، فمن المهم الانتباه إلى زيادة تعقيد إدارة الشبكة. حيث يعمل بروتوكول DHCP على تحسين إمكانية إدارة الشبكة من خلال السماح لمديري الشبكة network managers بضبط نطاقٍ من عناوين IP لكلّ شبكة بدلًا من عنوان IP واحد لكلّ مضيف.

نلاحظ أن بروتوكول DHCP قد يُدخِل أيضًا بعض التعقيد إلى إدارة الشبكة، لأنّه يجعل الربط بين المضيفين الفيزيائيين وعناوين IP أكثر ديناميكيةً. وهذا قد يجعل مهمّة مدير الشبكة أصعب إذا أصبح من الضروري تحديد موقع مضيف به خلل مثلًا.

الإبلاغ عن خطأ Error Reporting باستخدام بروتوكول ICMP

المشكلة التالية هي كيفية تعامل الإنترنت مع الأخطاء. يكون بروتوكول IP مستعدًا تمامًا لإهمال مخطَّطات البيانات عندما تصبح الأمور صعبة، وحين لا يعرف الموجّه كيفية تمرير مخطط البيانات أو عندما يفشل جزء واحد من مخطط البيانات في الوصول إلى الوجهة على سبيل المثال. لكنه لا يفشل بالضرورة بصمت، إذ يُضبَط بروتوكول IP دائمًا باستخدام بروتوكول مصاحب يُعرف باسم بروتوكول رسائل التحكم بالإنترنت Internet Control Message Protocol أو اختصارًا ICMP. والذي يحدّد مجموعةً من رسائل الخطأ التي تُرسَل مرةً أخرى إلى المضيف المصدر عندما يتعذّر على الموجّه أو المضيف معالجة مخطط بيانات IP بنجاح. إذ يحدّد بروتوكول ICMP رسائل الخطأ التي تشير إلى عدم إمكانية الوصول إلى المضيف الوجهة (ربما بسبب فشل الرابط)، إلى جانب فشل عملية إعادة التجميع، ووصول زمن TTL إلى الصفر، وفشل المجموع الاختباري لترويسة IP، وما إلى ذلك.

يحدّد بروتوكول ICMP أيضًا مجموعةً من رسائل التحكم التي يمكن للموجه إرسالها مرةً أخرى إلى مضيف المصدر. وتُعَدّ إحدى رسائل التحكم الأكثر فائدةً هي تلك المسماة ICMP-Redirect، والتي تُخبر المضيف المصدر بوجود مسار أفضل إلى الوجهة. كما تُستخدَم رسائل ICMP-Redirect في الحالة التالية: افترض أنّ مضيفًا متصلًا بشبكة فيها موجّهان متصلان بها يُطلق عليهما R1 وR2، بحيث يستخدم المضيفُ الموجّه R1 في صورة موجّه افتراضي خاص به. فإذا تلقّى الموجّه R1 مخطَّط بيانات من المضيف، فسيعرف استنادًا إلى جدول التمرير الخاص به، أنّ الموجّه R2 سيكون خيارًا أفضل لعنوان وجهة معيّن، وسيرسل رسالة ICMP-Redirect إلى المضيف، ويطلب منه استخدام الموجّه R2 لجميع مخططات البيانات المستقبلية الموجَّهة إلى تلك الوجهة، ليقوم المضيف بإدراج مسار التوجيه الجديد إلى جدول التمرير الخاص به. كما يوفر بروتوكول ICMP أيضًا الأساس لِأداتين من أدوات تنقيح الأخطاء debugging المستخدَمة على نطاق واسع، وهما ping وtraceroute. حيث تستخدم الأداة ping رسائل ICMP echo لتحديد ما إذا كانت العقدة قابلةً للوصول وفعّالة. كما تستخدم الأداة traceroute تقنيةً غير بديهية لتحديد مجموعة الموجّهات على طول المسار إلى الوجهة.

الشبكات الافتراضية Virtual Networks والأنفاق Tunnels

نختم مناقشتنا لبروتوكول IP من خلال النظر في قضية ربما لم تتوقعها، لكنها مهمّة. ركّزت مناقشتنا حتى الآن على تمكين العُقد الموجودة على الشبكات المختلفة من التواصل مع بعضها البعض بطريقة غير مقيّدة، وعادةً ما يكون هذا هو الهدف في الإنترنت، حيث يريد الجميع أن يكون قادرًا على إرسال بريد إلكتروني إلى الجميع، كما يريد منشئ موقع ويب جديد الوصول إلى أوسع جمهور ممكن. ولكن هناك العديد من المواقف التي تتطلّب اتصالًا أكثر تحكُّمًا. ومن الأمثلة المهمة على هذا نذكر حالةالشبكة الخاصة الافتراضية virtual private network أو اختصارًا VPN.

يُستخدَم مصطلح VPN بصورة مفرطة وتختلف تعريفاته، ولكن يمكن تعريف VPN من خلال التفكير أولًا في فكرة الشبكة الخاصة. حيث تبني الشركات التي لديها العديد من المواقع شبكاتٍ خاصة عن طريق استئجار داراتٍ من شركات الهاتف واستخدام هذه الخطوط لربط المواقع. حيث يقتصر الاتصال بين مواقع تلك الشركة فقط في مثل هذه الشبكة، وهو أمر مرغوب فيه غالبًا لأسباب أمنية. حيث تُستبدَل خطوط النقل المؤجّرة التي لا تتشاركها الشركة مع أية شركةٍ أخرى بنوعٍ من الشبكات المشتركة لإنشاء شبكة خاصة وهمية. وتُعَدّ الدَارة الافتراضية virtual circuit أو اختصارًا VC بديلًا معقولًا للغاية للخط المؤجّر leased line، نظرًا لاستمرارها بتوفير اتصال منطقيّ من نقطة لنقطة بين مواقع الشركة. فإذا كان لدى الشركة X دَارة افتراضية من الموقع A إلى الموقع B على سبيل المثال، من الواضح أنه يمكنها إرسال رزم بين الموقعين A وB. ولكن لا توجد طريقة تمكّن الشركة Y من تسليم رُزَمِها إلى الموقع B دون إنشاء دارتها الافتراضية أولًا إلى الموقع B. كما يمكن منع إنشاء مثل هذه الدارة الافتراضية إداريًا، وبالتالي منع الاتصال غير المرغوب فيه بين الشركة X والشركة Y.

يوضِّح القسم (أ) من الشكل الآتي شبكتين خاصتين لشركتين منفصلتين. حيث نُقِلت كلتا الشبكتين في القسم (ب) إلى شبكة دارة افتراضية. بحيث يبقى الاتصال المحدود للشبكة الخاصة الحقيقية، ولكن أُنشِئت شبكتين خاصتين افتراضيتين نظرًا لاشتراكهما الآن بنفس وسائل الإرسال والمبدّلات.

تُستخدَم شبكة دارة افتراضية في الشكل السابق (باستخدام تقنية ATM على سبيل المثال) لتوفير الاتصال المُتحكَّم به بين المواقع. كما يمكن أيضًا توفير وظيفة مماثلة باستخدام شبكة IP لتوفير الاتصال. ولكن لا يمكن ربط مواقع الشركات المختلفة بشبكة متشابكة واحدة فقط نظرًا لتوفيرنا بذلك اتصالًا بين الشركة X والشركة Y، وهو ما نرغب في تجنبه، ولحل هذه المشكلة سنحتاج إلى تقديم مفهومٍ جديد وهو نفق IP.

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

يشبه هذا الرابط الافتراضي ارتباطًا عاديًا في جدول التمرير الخاص بالموجّه عند مدخل النفق. وبافتراض الشبكة الموجودة في الشكل السابق على سبيل المثال، فقد ضُبِط نفقٌ من الموجّه R1 إلى الموجّه R2، وأُسنِد رقم واجهة افتراضي بقيمة 0، وبالتالي قد يبدو جدول التمرير في الموجّه R1 مثل الجدول التالي:

يحتوي الموجّه R1 على واجهتين فيزيائيتين هما: الواجهة 0 التي تتصل بالشبكة 1، والواجهة 1 التي تتصل بشبكة متشابكة كبيرة، وبالتالي فهي الشبكة الافتراضية لجميع حركات مرور البيانات التي لا تتطابق مع شيء أكثر تحديدًا في جدول التمرير. كما يحتوي الموجّه R1 على واجهة افتراضية أيضًا، وهي واجهة النفق.

بفرض استقبَل الموجّه R1 رزمةً من الشبكة 1 تحتوي على عنوان من الشبكة 2. وفقًا لجدول التمرير، يجب إرسال هذه الرزمة إلى الواجهة الافتراضية 0، بحيث يأخذ الموجّه الرزمة ويضيف ترويسة IP الموجهة إلى الموجّه R2 من أجل إرسال رزمةٍ إلى هذه الواجهة. لينتقل إلى تمرير الرزمة كما لو أنها اُستلِمت للتو، ويكون عنوان الموجّه R2 هو 18.5.0.1. بما أنّ رقم الشبكة لهذا العنوان هو 18، وليس 1 أو 2، فسيُعاد توجيه الرزمة الموجَّهة إلى الموجّه R2 عبر الواجهة الافتراضية default interface إلى الشبكة المتشابكة.

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

قد تتساءل عن سبب رغبة أيّ شخص في تحمُّل عناء إنشاء نفق وتغيير تغليف الرزمة أثناء مرورها عبر شبكة متشابكة، ومن بين أحد الأسباب هو الأمن security. إذ قد يصبح النفق بعد استكماله بالتشفير، نوعًا خاصًا جدًا من الروابط عبر شبكة عامة. أمّا السبب الآخر، فهو امتلاك الموجّهين R1 وR2 لبعض القدرات غير المتوفرة على نطاق واسع في الشبكات المتداخلة مثل توجيه البث المتعدد. إذ يمكن بناء شبكة وهمية من خلال توصيل هذه الموجّهات بنفق، بحيث تبدو جميع الموجّهات في هذه الشبكة التي لديها هذه الإمكانية متصلةً مباشرةً. بينما يُعَدّ السبب الثالث لبناء الأنفاق، هو حَمل الرزم باستخدام بروتوكولات أخرى غير بروتوكول IP خلال شبكة IP. وطالما أنّ الموجهات في أيٍّ من طرفيّ النفق تعرف كيفية التعامل مع هذه البروتوكولات الأخرى، فسينظر إليها نفق IP على أنّها رابط من نقطة لنقطة يمكن من خلاله إرسال رزمٍ مغايرة عن رزم IP. كما توفّر الأنفاق أيضًا آليةً يمكن من خلالها إجبار رزمة على تسليمها إلى مكانٍ محدَّد على الرغم من إمكانية إيحاء ترويستها الأصلية التي تُغلَّف داخل ترويسة النفق، بوجوب نقلها إلى مكان آخر. وهكذا نجد أنّ الأنفاق تقنية قوية وعامة جدًا لبناء روابط افتراضية عبر الشبكات المتشابكة، لذلك تتكرّر هذه التقنية مع حالة الاستخدام الأكثر شيوعًا والتي هي نفق IP عبر بروتوكول IP.

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

ترجمة -وبتصرّف- للقسم Internet من فصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: توجيه Routing الرزم ضمن الشبكات الحاسوبية
• المقال السابق: الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP