ما الذي يحدث فعلاً عند تشغيل VPN على لينكس

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

تظهر واجهة قبل أن يعمل أي شيء

يفتح عميل النفق واجهة افتراضية ويسلمها الحزم. جهاز TUN يحمل حزم IP، وهو ما يحتاجه VPN الموجّه؛ وجهاز TAP يحمل إطارات Ethernet، وهو ما يحتاجه التصميم الجسري. توفر وحدة النواة الجهاز، ويملكه العميل طوال مدة الجلسة.

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

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

المسارات يثبتها من يملك النفق

المسارات هي التغيير الثاني، وملكيتها تهم أكثر من محتواها. ملف تعريف NetworkManager ووحدة systemd وعميل يُدار يدوياً يمكنها جميعاً تثبيت المسارات، وقيام اثنين منها بذلك في الوقت نفسه ينتج جدولاً لا يستطيع أحد تفسيره لاحقاً.

ip -br addr show
ip route show
ip -6 route show

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

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

المحلل ينتقل إلى يد أخرى

DNS هو التغيير الثالث والأكثر احتمالاً لأن يُدار في مكان لم تنظر فيه. على سطح مكتب، قد يدفع NetworkManager إعدادات المحلل لكل اتصال. على نظام يستخدم systemd-resolved، تُطبق الإعدادات لكل رابط وقد يكون /etc/resolv.conf ملفاً وهمياً أو رابطاً رمزياً بدلاً من ملف يجب تحريره.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

إذا اختفى تحرير يدوي لملف المحلل بعد إعادة الاتصال، فهذه إشارة إلى العثور على المكوّن الذي يصونه وتغيير ملف التعريف بدلاً من ذلك. تحرير الملف المولَّد تغيير ستمحوه إعادة الاتصال.

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

مدير واحد لكل اتصال

صيغة ملف التعريف تحدد أي برنامج يمكنه استخدامه. ملف تعريف OpenVPN يحتاج OpenVPN أو إضافة متوافقة، ولكونفيغ WireGuard صيغته الخاصة بمفاتيح النظير والبادئات المسموح بها. مربع حوار الاستيراد لا يترجم أحدهما إلى الآخر، أياً كان امتداد الملف.

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

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

ما يجب فحصه عندما يكون قائماً لكنه لا يعمل

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

nmcli connection show --active
nmcli device status
wg show

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

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