مسارات L2TP المنقسمة على Mac: لماذا لا يعمل عنوان المضيف

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

الوجهة عنوان شبكة، والقناع يصف البادئة

networksetup -setadditionalroutes يأخذ ثلاثيات من الوجهة وقناع الشبكة الفرعية والبوابة. يبدو الاستدعاء الذي يرسل شبكة فرعية داخلية واحدة عبر النفق هكذا:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

لاحظ ما هي الوجهة: عنوان الشبكة، لا عنوان الخادم الذي تحاول الوصول إليه. في الحالة التي أنتجت هذا المقال، لم يفعل الأمر المطابق مع 192.168.1.20 في ذلك الموضع شيئًا مفيدًا، واستبداله بـ 192.168.1.0 عمل على الفور. القناع نفسه، والبوابة نفسها، ورقم واحد مختلف. هذا هو الفشل كله مصغرًا.

السبب حسابي لا سياسي. عنوان مضيف مقترن بقناع /24 لا يصف 192.168.1.0/24؛ بل يصف شيئًا لا يستطيع جدول التوجيه الاحتفاظ به بشكل مفيد، لذلك يُرفض الإدخال أو يُتجاهل وينتهي النفق بحمل أقل مما أردت.

عندما تريد مضيفًا واحدًا بالضبط، استخدم عنوان المضيف مع قناع 255.255.255.255. الأزواج المختلطة هي مكان الخطأ، لا استخدام عنوان المضيف بحد ذاته. مسار /32 مبني من عنوان واحد مسار مشروع؛ ومسار /24 مبني من عنوان واحد خطأ.

الاستدعاء يستبدل القائمة، والاسم حرفي

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

اسم الخدمة أيضًا ليس التسمية التي اخترعتها. اقرأه من الأداة وانسخه تمامًا، بما في ذلك لاحقة النوع:

networksetup -listallnetworkservices

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

عندما يطالب الملف الشخصي بالمسار الافتراضي

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

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

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

أنفاق PPP تحتاج إلى خطاف بدلًا من مفتاح

في الأنفاق القائمة على PPP، يكون defaultroute هو مفتاح الملف الشخصي الذي ينشئ مسارًا افتراضيًا؛ أسقطه ويتوقف العميل عن المطالبة بكل وجهة. تُضاف المسارات بعد ذلك بعد ظهور الواجهة، عادةً من /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

أبقِ السكربت مملوكًا لـ root وقابلًا للتنفيذ، وأضف حارسًا على اسم الواجهة عندما يوجد أكثر من ملف نفق واحد على الجهاز. الخطاف الذي يعمل لكل وصلة PPP ويفترض اسم جهاز واحد هو خطأ صغير بعمر طويل.

تحقق من الانقسام بثلاثة طلبات

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

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

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