تطبيقا VPN في آن واحد: أي kill switch ينطبق فعلاً؟
العميل الثاني لـVPN لا يرث أبداً kill switch الأول. ثلاثة شروط تحدد أي سياسة تنطبق، وكيف تتحقق من سياستك.
يمكن أن يعمل عميلا VPN جنباً إلى جنب، لكن kill switch الخاص بهما لا يندمج في سياسة واحدة. كل عميل يثبّت قواعد لنفقه الخاص، ولا يعرف أي منهما أن الآخر موجود. صادفت هذا مع عميل عمل متصل أولاً: لم يستطع التطبيق الثاني إكمال المصافحة، وبقي على «Connecting» عشر دقائق، ونقل النفق الأول كل شيء بهدوء. أما حماية التطبيق الثاني فتتوقف على ثلاثة شروط، لا على ما إذا كان الرمزان كلاهما يقول «متصل».
ما الذي يقتصر عليه kill switch فعلاً
لا يوجد في نظام التشغيل علم kill switch واحد. العميل الذي يعلن عن واحد يثبّت مجموعة قواعد: أسقط كل ما لا يخرج عبر نفقي، وغالباً fail closed عندما يختفي النفق. على Linux تكون غالباً سلسلة nftables أو iptables، وعلى Windows مجموعة مرشحات Windows Filtering Platform، وعلى Android وiOS توجيه خدمة النفق نفسها إضافة إلى إعداد النظام الذي يحجب الاتصالات بلا VPN. يصف دليل VPN في Android نموذج الخدمة هذا إن أردت منظور المنصة.
النطاق هو الجزء المهم. قاعدة مثل «اسمح فقط بالحزم على واجهة الخروج wg0» لا تهتم بوجود نفق ثانٍ. إذا رفع عميل آخر wg1، تعامل قواعد العميل الأول تلك الحزم كمرور عادي: تُسقط غالباً، وتُسمح أحياناً. في كل الحالات يقرر العميل الأول، وليس لديه فكرة أن تطبيقاً ثانياً ينتظر.
ثلاثة شروط تحدد من يُغطى
لا تحتاج إلى تعداد كل تركيبة. ثلاثة أسئلة تحسم الأمر في دقائق.
- هل تسمح المنصة أصلاً بنفق ثانٍ؟ معظم هواتف Android وأجهزة iPhone تقبل خدمة VPN نشطة واحدة لكل ملف مستخدم، لذا لا يحصل التطبيق الثاني أبداً على نفق ولا ينفذ شيئاً. تحصل على سياسة واحدة، من التطبيق الذي فاز بالمكان.
- أي عملية تملك المسار الافتراضي؟ تحمل Windows وmacOS وLinux نفقين بسهولة. المسار الافتراضي يخص العميل الذي أعدّه أخيراً أو بمقياس أفضل، والعميل الآخر متصل لكن عاطل. على Linux يستخدم وضع المسار الافتراضي في wg-quick توجيهاً قائماً على السياسة مع جدول خاص وقاعدة fwmark، لذا يضيف نفق wg-quick الثاني قاعدة منافسة بدل استبدال الأولى.
- هل يستطيع العميل الثاني الوصول إلى خادمه؟ إذا كان kill switch الأول رفضاً افتراضياً، فإن نقطة النهاية الخارجية للتطبيق الثاني مجرد وجهة أخرى تُسقط. يعيد المحاولة بصمت ولا يبلّغ عن خطأ أبداً.
النسخة القصيرة، لخيوط الدعم:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
صفّان من تلك الصفوف يبدوان متطابقين من رمز شريط النظام، ولهذا يكون الرمز أسوأ دليل متاح هنا.
ما الذي يفشل أولاً، وكيف يبدو
عميل عالق على «Connecting» بينما الآخر سليم يعني دائماً تقريباً جوعاً إلى نقطة النهاية: kill switch العامل يُسقط مصافحة العميل الثاني نحو خادمه. تحقق من ذلك بثمن بخس بإيقاف قواعد الحجب للعميل الأول مؤقتاً لمحاولة واحدة. إذا اتصل الثاني فوراً، فقد أُجيب السؤال.
DNS هو الفشل الثاني. يضبط العملاء إعداد المحلل لواجهتهم، وبعضهم يكتب فوق القائمة العالمية ببساطة. مع النفقين مرفوعين، قد تخرج الاستعلامات من جانب بينما المحلل يخص الجانب الآخر. افصل أي تطبيق فيحتفظ الناجي بخادم أسماء غير قابل للوصول: تتوقف الصفحات دقيقة ثم تُحلّ من جديد، بينما يعرض VPN حالة الاتصال.
الثالث هو رفرفة المسارات. إعادة الاتصال تعيد ترتيب المسار الافتراضي، وkill switch المرتبط بواجهة لا يتبعه. المرور الذي كان داخل النفق قبل لحظة يطابق الآن قاعدة إسقاط، وهو ما يُقرأ من جهة المستخدم كأن VPN توقف عن العمل عشوائياً.
تحقق من أي سياسة سارية فعلاً
افعل ذلك بمرور غير ضار، لا بشيء ستفتقده.
على Linux اسأل النواة من يفوز وبماذا يرتبط الجدار الناري. ip -4 route show default يسمّي النفق الذي يملك الخروج. ip rule show يبيّن هل التوجيه القائم على السياسة في اللعبة. sudo nft list ruleset | grep -n oifname يبيّن هل الإسقاطات مرتبطة باسم واجهة أو بعلامة أو بسلسلة الخروج كلها.
على Windows تعيش القصة نفسها في مقياس المسار وقائمة المرشحات: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric و Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". على macOS، netstat -rn -f inet | head -5 و scutil --dns | head -20.
ثم افعل الخطوة التي يتخطاها الناس: أوقف النفق عمداً وتأكد من أن المرور الذي تتوقع فشله يفشل فعلاً. رمز متصل حالة واجهة، لا إنفاذ.
متى يكون عميلان التصميم الخاطئ
إذا كان الشرط الوحيد خلف التطبيق الثاني مزيداً من الحماية، أزله. سياستان للحجب تتفاعلان أقل قابلية للتنبؤ من واحدة، وكل إعادة اتصال فرصة للوقوع في حالة لا يختبرها أي مورّد.
إذا كنت تحتاج فعلاً إلى تسلسل، مثل بوابة مؤسسية تُبلغ عبر قفزة تجارية، فاختر تصميماً بنقطة إنفاذ واحدة. يعني ذلك عادة راوتراً أو عميلاً واحداً يدعم السلسلة، لا تطبيقَي سطح مكتب يتنافسان على المسار الافتراضي نفسه. على جهاز مُدار أبقِ العميل المعتمد واعتبر كل ما عداه خارج النطاق، مهما عرض في شريط النظام.
قائمة تحقق قبل الإبقاء على كليهما
امشِ في القائمة بالترتيب؛ أول بند يفشل هو الذي يجب إصلاحه.
- تأكد من أن عميلاً واحداً بالضبط يملك المسار الافتراضي والمحلل.
- إن أردت العميل الثاني مرفوعاً، فاسمح صراحةً بنقطة نهاية خادمه وأعد الفحص بعد كل تحديث للعميل.
- سجّل النتيجة المتوقعة عند سقوط أي نفق، واختبر تلك الحالة بعينها.
- افحص مسار الفشل بعد إعادة التشغيل، حين يكون ترتيب البدء مختلفاً.
- على ملف مُدار توقف واسأل المالك قبل إضافة أي شيء.
إذا فشلت الخطوة الثالثة، فالجواب الصادق أن عميلاً واحداً فقط يمنحك سياسة. قرر أيّهما تثق به واترك الآخر.