لماذا يقطع نفق VPN ثانٍ النفق الأول؟

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

العَرَض: العميل الثاني يفوز بهدوء

OpenVPN لا يستبدل خيار redirect-gateway def1 المسار 0.0.0.0/0. بل يضيف 0.0.0.0/1 و 128.0.0.0/1: ومجموعهما يغطي كل عنوان IPv4، وكل بادئة تغلب المسار الافتراضي العادي من حيث الطول. يبقى المسار الافتراضي الأصلي في الجدول ويتوقف استخدامه لحركة المرور العادية، ويحافظ مسار مضيف إلى خادم VPN على النفق بحيث لا يلتقط حزمه الخارجية. كلا العميلين يفعل ذلك، والثاني يثبّت زوجه لاحقًا فحسب.

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

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

اقرأ أي نفق يفوز فعليًا

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

ويندوز: امنع ملفًا شخصيًا واحدًا من امتلاك المسار الافتراضي

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

لينكس: أخرج النفق الثاني من الجدول الرئيسي

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

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

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

لكل تطبيق، والتسلسل كمشكلة منفصلة

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

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

اكتب مالك المسار الافتراضي، وقائمة البادئات التي يحملها كل نفق، ومسار DNS. تلك الحقائق الثلاث تحوّل الحادثة التالية إلى بحث بدل تحقيق.