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

ماذا يفعل كل علم بالمسار الافتراضي

بدون أي علم على الإطلاق، يزيل الخيار المسار الافتراضي العادي ويضع النفق مكانه، فتختفي البوابة القديمة من الجدول ما دام الاتصال قائمًا. أضف def1 فيبقى ذلك الافتراضي مدرجًا، مع مسارين أضيق يقومان بالعمل بدلًا منه. أضف bypass-dhcp فيبقى مسار DHCP أيضًا، وهذا مهم على شبكة لا يزال على العميل فيها الوصول إلى خادم DHCP المحلي. قائمة الأعلام في صفحة دليل OpenVPN 2.6 قصيرة بما يكفي لقراءتها مرة واحدة، وكل بند يغيّر المسارات التي تنتهي في الجدول.

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

def1 يفوز بالتحديد دون المساس بالافتراضي

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

اقرأ الجدول بدلًا من الملف الشخصي، لأن الجدول وحده يبيّن في أي من تلك الحالات أنت. سطران يكفيان للتفريق بينهما:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

أبقِ طرف النفق الآخر قابلًا للوصول

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

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

ip route get 198.51.100.20

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

حركة IPv6 تظل تستخدم جدولها

إعادة توجيه IPv4 تترك IPv6 وشأنه، والعائلتان تغيّرهما أعلام مختلفة. على مضيف ثنائي الحزمة فيه افتراضي v6 عامل، يمكن أن تبقى حركة v4 داخل النفق بالكامل بينما كل وجهة قادرة على v6 تخرج عبر الوصلة الفيزيائية. المضيف الذي يبدو صحيحًا في جدول واحد يسرّب في الآخر.

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

ip -6 route show default
ip -6 route get 2001:db8::10

أثبت أي واجهة يستخدمها التطبيق

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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

مقالات ذات صلة