مسارات دائمة لشبكة VPN على Mac: networksetup أم خطاف اتصال؟

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

حدد ما إذا كان المسار يخص الخدمة أم الجلسة

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

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

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

اقرأ حالة المسار والخدمة الحالية

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

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

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

لاحظ عنوان النظير أثناء الاتصال. يصبح قيمة البوابة في المسار المرتبط بالخدمة، وهو عادة الوجهة المعروضة لمسار النفق الافتراضي في netstat -rn.

خزّن البادئة باستخدام networksetup

أداة networksetup تربط مسارات إضافية بخدمة شبكة. بالنسبة لخدمة باسم OfficeVPN وبادئة خاصة يُوصل إليها عبر نظير النفق، تكون الصيغة:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

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

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

استخدم route add للاختبار فقط

المسار المباشر مفيد لإثبات أن بادئة تعمل قبل جعلها دائمة. صيغة الواجهة تتجنب البحث عن بوابة:

sudo route -n add -net 10.20.0.0/16 -interface utun4

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

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

اختر خطافًا فقط عندما يُتفاوض على العنوان

بالنسبة لروابط PPP مثل L2TP، ينفذ macOS /etc/ppp/ip-up بمجرد إنشاء الرابط. يتلقى السكربت اسم الواجهة والعناوين المحلية والبعيدة المتفاوض عليها، فيمكنه إضافة مسار يعتمد على النظير الذي خصصه الخادم. هذه بالضبط الحالة التي لا يستطيع مسار خدمة ثابت التعبير عنها.

قد لا تستخدم IKEv2 وعملاء البائعين مسار PPP هذا إطلاقًا، ما يعني أن السكربت قد يبقى صامتًا طوال الجلسة. عندما يحدث ذلك، فإن وظيفة launchd التي تستطلع scutil --nc status وتتحرك عند تغير الحالة هي الآلية المكافئة، مع تأخير صغير.

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

أنهِ بفحص الوجهة الخاصة والتصفح العادي ودورة إعادة اتصال أو سكون. ثم افحص scutil --dns، لأن تحليل الأسماء سياسة منفصلة ومسار عامل لا يثبت أن الأسماء الخاصة تُحل.