Fexyn
Fexyn
All posts

ما الذي يفعله VPN kill switch فعلياً (ولماذا معظمها لا يعمل)

Fexyn Team··5 min read

VPN kill switch هو ميزة تحجب كل حركة الإنترنت عند انقطاع اتصال VPN. الهدف: أن لا يتسرب IP الحقيقي خاصتك بينما العميل يعيد الاتصال. كل VPN يقول إن لديه واحداً. معظمها لا يعمل.

المشكلة في مكان وجود kill switch. إذا كان يعيش داخل تطبيق VPN — يستطيع التفاعل فقط بعد أن يلاحظ التطبيق الانقطاع. هذا كود userland في سباق مع نظام تشغيل وجّه حزم البيانات بالفعل.

فجوة الـ 200 مللي ثانية التي لا يتحدث عنها أحد

ما يحدث عندما ينقطع نفق VPN بدون kill switch على مستوى kernel:

  1. النقطة البعيدة تتوقف عن الاستجابة. ربما أُعيد تشغيل الخادم، ربما تغيرت الشبكة، ربما حدث routing flap.
  2. ملاحظة العميل لذلك تستغرق من 200ms إلى عدة ثوانٍ. معظم العملاء يستخدمون فحص حالة بنمط heartbeat. WireGuard يرسل ping كل 25 ثانية افتراضياً. keepalive في OpenVPN قابل للتكوين لكن عادةً 10-60 ثانية.
  3. خلال تلك الفجوة، نظام التشغيل لا يزال يعتقد أن النفق مفتوح. يستمر في توجيه الحركة إلى واجهة النفق.
  4. واجهة النفق تُسقط الحزم — لكن في بعض التكوينات، fallback routing يتدخل وتخرج الحزم من واجهتك الحقيقية. متصفحك يستمر في إرسال الطلبات، عميل البريد يستمر بالـ poll، عملاء IM يحافظون على جلسات TCP حية.
  5. الخوادم الهدف تسجل IP الحقيقي خاصتك. خدمة البث تحدّث سجل الجلسة. ISP يرى استعلام DNS بنص واضح كان من المفترض أن يُحلّ داخل النفق.

عندما يستيقظ عميل VPN ويُفعّل userland kill switch — التسريب حدث بالفعل.

هذا هو معظم kill switches في VPN. تنشط بعد الحدث.

أين يعيش kill switch الحقيقي

Kill switch على مستوى kernel لا يعيش في عملية عميل VPN — يجلس في network stack الخاص بنظام التشغيل. على Windows هذا هو Windows Filtering Platform — نفس firewall API الذي يستخدمه Windows Defender Firewall. على macOS، Network Extension framework. على Linux، قواعد nftables/iptables مع PF_INET hooks.

ثلاث خصائص تجعله يعمل:

يعمل قبل اكتمال VPN handshake. عند الضغط على Connect، يتم إعداد فلاتر kill switch أولاً. الـ handshake يمر عبر فتحة يفتحها kill switch خصيصاً لنقطة VPN. إذا فشل handshake، لا شيء يخرج.

ينجو من تعطل العميل. إذا مات عملية تطبيق VPN، يستمر kill switch في الحجب. Userland kill switches تموت مع تطبيقاتها — وWindows يستعيد التوجيه الطبيعي بسعادة في اللحظة التي يخرج فيها التطبيق.

ينجو من تغيرات الشبكة، sleep وresume. الانتقال من Wi-Fi إلى ethernet، إغلاق الغطاء، hibernate، تبديل hotspot — كل هذه أحداث على in-app kill switch معالجتها كتغيرات state منفصلة. قواعد WFP أسفل ذلك. تبقى في مكانها حتى تُزال صراحةً من قبل عملية مخوّلة.

كيف يطبّقه Fexyn

عميل Fexyn على Windows ينقسم إلى جزأين: واجهة UI بصلاحيات المستخدم وخدمة helper بصلاحيات SYSTEM. فلاتر WFP تملكها خدمة helper فقط. عند الضغط على Connect:

  1. تُعدّ خدمة helper فلاتر WFP — تحجب كل الحركة الصادرة باستثناء: (أ) loopback، (ب) نقطة VPN endpoint:port المحددة، و(ج) DHCP/DNS إلى local gateway للـ handshake.
  2. VPN handshake يمر عبر تلك الفتحة المفتوحة.
  3. عند رفع النفق، routing table يرسل كل شيء إلى واجهة النفق. فلاتر WFP تبقى في مكانها؛ فقط لا ترى معظم الحركة لأن النفق الآن هو مسار أقل مقاومة.
  4. إذا انقطع النفق، routing table يفقد route النفق. الحركة تعود إلى الواجهة الافتراضية. فلاتر WFP تحجبها. متصفحك يُظهر خطأ "لا يوجد إنترنت". IP الحقيقي خاصتك يبقى مخفياً.
  5. عندما يعيد helper الاتصال بنجاح، نقطة النفق الجديدة قد تكون مختلفة. helper يحدّث الـ carve-out، والحركة تتدفق مرة أخرى.

المستخدم لا يُعطّل شيئاً. واجهة المستخدم لا تطلب admin أبداً. Kill switch لا يعتمد على بقاء واجهة المستخدم حية.

ماذا يعني هذا عملياً للمناطق ذات المراقبة العالية

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

Kill switch على مستوى kernel يغلق نافذة التسريب تلك. افتح Wireshark وأجبر VPN على الانقطاع (انزع الشبكة، بدّل Wi-Fi، علّق الجهاز). مع userland kill switch، ستشاهد بعد الانقطاع لفترة — عادةً من 200ms إلى عدة ثوانٍ — تدفق الحزم على الواجهة الأساسية. مع kill switch قائم على WFP، لن ترى شيئاً حتى يعيد النفق الاتصال أو حتى توقف kill switch صراحةً.

الثاني هو ما تريده.

ما لا يحلّه kill switch

Kill switch يحلّ مشكلة محددة: تسريبات الحركة أثناء انتقالات النفق. لا يفعل:

  • لا يحمي من نقطة نهاية مخترقة. إذا كان laptop خاصتك مصاباً، الـ malware يرى الحركة قبل أن يراها الـ kernel.
  • لا يوقف تسريبات DNS لوحده. منع تسريب DNS طبقة منفصلة (NRPT على Windows، force-DNS-through-tunnel في تكوين البروتوكول). Kill switch وحده لا يصحّح DNS مكوّن خطأً.
  • لا يمنع تسريبات WebRTC. WebRTC في المتصفح يعمل فوق مستوى الشبكة؛ المتصفح يعرف IP الحقيقي خاصتك بغض النظر عما تراه الشبكة. إصلاح مختلف تماماً.

أسئلة عند تقييم VPN

إذا كنت تقيّم kill switch لـ VPN، الأسئلة هي:

  1. هل يعمل قبل اكتمال handshake، أم بعده فقط؟
  2. هل ينجو حتى لو تعطل عميل VPN؟
  3. قاعدة firewall على مستوى kernel أم userland reconnect loop؟
  4. هل يسمح بـ loopback — حتى تستمر خوادم التطوير المحلية بالعمل؟

الإجابات الصادقة عادةً ليست في نص التسويق، بل في وثائق المنتج. نص التسويق سيقول دائماً "kill switch" — دون أن يخبرك أي نوع.

لـ Fexyn:

  • قائم على WFP، على مستوى kernel
  • يعمل قبل handshake
  • ينجو من تعطل helper-service، sleep، resume، وتغيير الشبكة
  • يسمح بـ loopback (127.0.0.0/8 و ::1) وlink-local

قراءة ذات صلة

جرّب Fexyn مجاناً لمدة 7 أيام. Kill switch مفعّل افتراضياً — لا تحتاج إلى تشغيله.

ما الذي يفعله VPN kill switch فعلياً (ولماذا معظمها لا يعمل) | Fexyn VPN