إعادة توجيه ICMP مقابل مسارات VPN: ما الذي يتغير فعلًا
إعادة التوجيه اقتراح من الموجّه، وليست تغييرًا في المسار. أمّا إذا كان المضيف يطيعها فيعتمد على سياسة لكل واجهة تختلف بين IPv4 وIPv6.
تدفّق يُفترض أن يعبر النفق يتخذ قفزة تالية مختلفة، فيجد أحدهم إعادة توجيه ICMP في لقطة التقاط. هذا فرض، وليس تشخيصًا. إعادة التوجيه اقتراح من الموجّه بشأن قفزة تالية أفضل، وما إذا كان المضيف يتصرف بناءً عليه يعتمد على إعدادات تختلف حسب المنصة والواجهة وعائلة العناوين.
إعادة التوجيه اقتراح من الموجّه
لإعادات توجيه ICMP في IPv4 نوع رسالة خاص بها ومجموعة ضيقة من الشروط: يرسل الموجّه الحزمة عبر الواجهة التي وصلت منها، ويعرف قفزة تالية على الرابط نفسه أقرب إلى الوجهة. ثم يطلب من المرسل استخدام تلك القفزة التالية مباشرة. تذكر الرسالة البوابة الجديدة وتضمّن جزءًا من الحزمة الأصلية كي يستطيع المرسل مطابقتها بتدفق. إنها رسالة مجاملة عن الطوبولوجيا المحلية، وتفترض أن المرسل يتشارك رابطًا مع البوابة المقترحة.
المرسل حرّ في تجاهلها. لا شيء في البروتوكول يُلزم المضيف بتغيير جدوله، وإعادة توجيه مُلتقطة تثبت فقط أن موجّهًا أرسلها.
هذا التمييز هو حيث تخطئ معظم تحقيقات إعادة التوجيه.
IPv4 وIPv6 يسلّمانها بطريقتين مختلفتين
لدى IPv6 آلية مماثلة داخل اكتشاف الجيران بدلًا من ICMPv4، بتنسيقات رسائل مختلفة وقواعد تحقق مختلفة. المفاهيم تتشابه أمّا الحزم فلا. مرشّح التقاط مكتوب لنوع ICMP 5 لن يُظهر شيئًا على شبكة IPv6، وهو ما يُقرأ أحيانًا كدليل على عدم وقوع أي إعادة توجيه.
مقابض السياسة منفصلة أيضًا، فيمكن لمضيف أن يقبل إعادات توجيه IPv4 ويتجاهل إعادات IPv6، أو العكس.
افحص العائلتين إن كان التدفق المعني قد يستخدم أيًّا منهما.
القبول سياسة مضيف، وليس حقيقة شبكة
على Linux، يُتحكّم في قبول إعادة التوجيه لكل واجهة وعلى المستوى العام، وتختلف القيم الافتراضية بين دور المضيف ودور الموجّه. واجهة نفق تقبل إعادة التوجيه تصميم غريب، إذ لا توجد قفزة تالية بديلة ذات معنى على الرابط نفسه داخل نفق نقطة إلى نقطة. وهذا يجعل الإعداد جديرًا بالقراءة لا بالافتراض.
إعدادات إعادة التوجيه الآمنة تزيد تقييد البوابات التي يجوز الوثوق بها.
إذا كنت تُحكم إعدادات مضيف، فهذه هي المقابض التي يجب مراجعتها، وهي أيضًا سبب اختلاف سلوك جهازين على الشبكة نفسها. غيّرها كسياسة، لا كاختصار لتصحيح الأخطاء.
ما لا تستطيع إعادة التوجيه تفسيره
المسارات المحددة وقواعد توجيه السياسة والواجهات المحلية تفسّر معظم المسارات غير المتوقعة دون أي إعادة توجيه على الإطلاق. بادئة أكثر تحديدًا، أو قاعدة تطابق عنوان المصدر، أو افتراضي ثانٍ في جدول آخر ستتجاوز كل واحدة منها المسار الذي توقعته. افحصها أولًا، لأنها حتمية ومرئية.
اللقطات القديمة هي الفخ الآخر، لأن العميل الذي غيّر شبكته لديه بوابة محلية مختلفة.
إعادة توجيه قديمة من الارتباط السابق لا تفسّر شيئًا عن المسار الحالي، لذا سجّل أي واجهة تستقبل حركة التحكم الآن.
افحص المسار قبل أن تلوم النفق
اسأل النواة أي مسار ستستخدمه للوجهة، ثم قارن ذلك بالجدول الذي قصدته. إن طابق الجواب الجدول، فلم تغيّر أي إعادة توجيه شيئًا والتحقيق ينتمي إلى مكان آخر. وإن لم يطابق، فابحث عن إعادة توجيه مخزّنة أو قاعدة سياسة أو جدول ثانٍ قبل افتراض أن النفق هو السبب. البحث هو الحقيقة الأساسية، وكل ما عداه حكاية عن كيفية وصول الأمر إلى هناك.
لا ينبغي أن تكون إعادة التوجيه أبدًا سببًا في أن يصبح مسار محمي مسارًا غير محمي بصمت، ولهذا تنتمي سياسة القبول إلى مراجعة التصميم. تعريف RFC 792 يبقى المرجع لما يُسمح لرسالة IPv4 بقوله.
اكتب بحث المسار وطابع وقت الالتقاط معًا، وسيتمكن الشخص التالي من إعادة إنتاج استنتاجك.