عنوان peer في PPP أم نقطة نهاية VPN: أيهما يُكتب في via

سطر واحد على واجهة PPP يحسم معظم جدل التوجيه على صندوق VPN: العنوان الداخلي والـ peer المطبوع بجانبه. اقرأ هذا الزوج كشبكة فرعية صغيرة وستبحث عن بوابة غير موجودة. اقرأه كطرفي ارتباط واحد فتصبح القفزة التالية بديهية. المقارنة هنا بين هاتين القراءتين، لأن كل جدول تبنيه بعد ذلك يرث ما اخترته. ولا واحدة منهما تقرر شيئًا بشأن نقطة نهاية VPN الخارجية.

قراءتان لسطر واجهة واحد

خُذ جلسة تعلن فيها الواجهة inet 10.64.3.9 peer 10.64.3.1/32. تقرأ قراءة الشبكة الفرعية 10.64.3.9 كمضيف وحيد على جزيرة /32 ثم تبحث عن موجّه للوصول إلى أي شيء خارجها. ولأن العنوان الآخر الوحيد على الارتباط هو الـ peer، تنتهي تلك القراءة باقتراح 10.64.3.9 نفسه كبوابة، وهذا دائري.

قراءة نقطة النهاية هي الموثقة. على واجهة نقطة إلى نقطة، يسمّي peer الطرف البعيد لذلك الارتباط الواحد، لذا فإن 10.64.3.1 هو القفزة التالية القابلة للاستخدام و10.64.3.9 ليس إلا عنوان مصدر.

هذا الفرق يحكم ما يمكن أن يظهر في via. كتابة العنوان المحلي هناك تُنتج مسارًا لا يستطيع النواة تحليله إلى جار، فإما تفشل الإدخالة في التحقق أو تبتلع حركة المرور بينما تبدو سليمة تمامًا في قائمة. يعمل الـ peer لأنه وجهة حقيقية على الارتباط. تتفق القراءتان على نقطة نهاية VPN الخارجية، وهي هوية منفصلة تمامًا: يُوصل إليها عبر الطبقة السفلية، لا عبر النفق الذي تنهيه.

ما ثبّته الجلسة سلفًا

قبل كتابة أي جدول خاص بك، اطبع ما جاء مع الارتباط. عادةً يثبّت تكامل PPP المدعوم مسار جهاز ومسار peer أثناء إعداد الجلسة، وهذان الإدخالان يرمزان بالفعل إلى القراءة الصحيحة.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

مسار جهاز مثل 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 لا يحمل بوابة لأن الواجهة نفسها هي المسار. والمسار الذي يسمّي الـ peer بـ via كائن آخر بعمر آخر، ويختفي عند سقوط الجلسة. نسخ أي من الشكلين إلى جدول دائم دون فحص كيفية إعادة تثبيته هو السبب المعتاد لفقدان نفق عامل مساره بعد إعادة الاتصال.

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

القاعدة والجدول قراران منفصلان

اختيار جدول وملؤه خطوتان مستقلتان، والمقارنة تهم هنا لأن الاثنين كثيرًا ما يُخلطان أثناء التصحيح. القاعدة التي ترسل حركة موسومة إلى الجدول 100 لا تفعل شيئًا إذا لم يكن في الجدول 100 مسار مطابق، والجدول الممتلئ جيدًا غير قابل للوصول إذا لم تشِر إليه أي قاعدة.

نصف مسار افتراضي ليس مسارًا افتراضيًا. 0.0.0.0/1 واحدة تغطي النصف الأدنى من فضاء IPv4، لذا تحتاج سياسة تنوي التقاط كل شيء إلى 128.0.0.0/1 المطابق أيضًا، أو إلى default حقيقية. قراءة إعداد يعمل ونسخ أحد النصفين هو الطريق الذي ينتهي به الناس إلى حلقة توجيه لا تنكسر إلا عند وجهات معينة.

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

اسأل البحث السؤال الذي يسأله تطبيقك

يحلّ ip route get مسارًا، ويسرد ip route show الإدخالات المخزنة، وقد يختلف الاثنان دون أن يكون أي منهما خاطئًا. أدرج سياق المصدر، لأن القواعد القائمة على المصدر لا تطابق إلا عندما يحمل البحث مصدرًا.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

حتى البحث الصحيح يثبت فقط أن مسارًا اختير. ولا يقول شيئًا عن قبول الطرف الآخر للحركة أو عن إمكان عودة الرد بالمنطق نفسه.

أين تنقلب المقارنة

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

إذا اختفت الردود بينما يبدو التوجيه الصادر صحيحًا، فاقرأ القيم الفعلية قبل لمسها، ولا تغيّرها إلا بسبب سياسة معلن.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

اختر بين التصميمين بناءً على الدليل: إذا ارتبط التطبيق بعنوان PPP، فتكفي قاعدة مصدر وجدول يحمل مسار الـ peer. وإذا كان الصندوق يُمرّر لشبكة محلية خلفه، فتحتاج أيضًا إلى توافق سياق الدخول ومسار العودة. وعندما لا يتفقان، صحّح ملكية المسار بدل تخفيف التحقق على مستوى الجهاز كله.