كيف تكشف تسريبات DNS موقعك بصمت، حتى مع تشغيل VPN

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

هذا المنشور يشرح المسارات الأربعة الشائعة للتسرّب، كيف تختبرها، وكيف يغلقها Fexyn.

من أين تأتي التسريبات

1. Smart Multi-Homed Name Resolution (SMHNR)

Windows 8 قدّم ميزة تُدعى Smart Multi-Homed Name Resolution. ترسل استعلامات DNS بالتوازي إلى كل خادم DNS متاح وتستخدم أي رد يأتي أولاً. الهدف كان تسريع تحليل DNS للمستخدمين بواجهات شبكة متعددة.

النتيجة، مع تشغيل VPN: استعلامات DNS خاصتك تذهب إلى كل من resolver الخاص بـ VPN (داخل النفق) وresolver الخاص بـ ISP (خارج النفق) في نفس الوقت. ISP يرى الاستعلام بغض النظر عما إذا فاز رد VPN بالسباق.

تغيّر هذا قليلاً في Windows 10 — SMHNR من المفترض أن يفضّل نفق VPN عند وجوده. عملياً، لا يفعل دائماً. السلوك يعتمد على ترتيب metric للمحوّل، Network Connectivity Status Indicator (NCSI)، وأي واجهة يعتبرها Windows "أساسية" في أي لحظة. التسريبات متقطعة، وهو أسوأ نوع: اختبار واحد يمر، لكن الاستخدام الفعلي يتسرّب.

2. سقوط IPv6

معظم بروتوكولات VPN تنفق IPv4 فقط. إذا أعطاك ISP خاصتك اتصال IPv6 (معظمهم، في 2026) وكان جهازك يفضّل IPv6 على IPv4، فعمليات بحث DNS قد تأخذ مسار IPv6. استعلام IPv6 يخرج من واجهتك الحقيقية، يصل إلى resolver IPv6 الخاص بـ ISP، وISP يرى البحث.

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

3. DNS-over-HTTPS في المتصفح

Chrome وFirefox وEdge وBrave الحديثة تستطيع فعل DNS-over-HTTPS إلى resolver عام (Cloudflare، Google، Quad9، NextDNS). عندما يكون DoH نشطاً، يتجاوز المتصفح طبقة DNS الخاصة بالنظام بالكامل.

هذا جيد للخصوصية من ISP — DoH إلى Cloudflare أكثر خصوصية من resolver الخاص بـ ISP. هو سيء لـ DNS المُنفَق عبر VPN، لأن المتصفح الآن يتحدث إلى Cloudflare مباشرة عبر الواجهة الأساسية (DoH يستخدم HTTPS، الذي يوجّهه نظام التشغيل عبر الواجهة النشطة — وهذه نفق VPN فقط إذا نفق VPN كل شيء).

النتيجة: مختبرو تسريب DNS الذين يتوقعون أن كل DNS يأتي من resolver خاص بـ VPN يضعون علامة على المتصفحات التي تستخدم DoH كـ "مسرّبة." سواء كان هذا تسريباً فعلاً يعتمد على أي نموذج تهديد تهتم به.

4. WebRTC وSTUN

WebRTC هو browser API لاتصالات peer-to-peer. يستخدم خوادم STUN لاكتشاف IP العام خاصتك. تبادل STUN يعمل فوق network stack — المتصفح يعرف IP الحقيقي خاصتك محلياً ويخبر الصفحة عند السؤال.

هذا ليس تسرّب DNS بحد ذاته، لكنه مجاور. صفحة تشغّل WebRTC تستطيع تعلّم عنوان IP الحقيقي خاصتك حتى مع VPN نشط وحتى مع كل DNS خاصتك يمر عبر النفق. إصلاح مختلف تماماً.

اقرأ منشور WebRTC لذلك.

كيف تختبر

استخدم أداة اختبار تسريب DNS من Fexyn أثناء توصيل VPN. فحصان:

اختبار قياسي. دفعة واحدة من الاستعلامات. يلتقط التسريبات المتسقة.
اختبار موسّع. ست جولات منتشرة بمرور الوقت. يلتقط التسريبات المتقطعة من SMHNR أو سباقات أولوية المحوّل.

النتيجة يجب أن تُظهر فقط resolvers يديرها مزود VPN. إذا أظهرت resolvers الخاصة بـ ISP (أو اسم ISP في أي من الإدخالات)، لديك تسرّب.

ماذا يرى مهاجم أو ISP من تسرّب

كل استعلام DNS متسرّب يعطيهم:

الدومين الدقيق الذي تبحث عنه
الـ timestamp
التكرار (إذا تكرر)
نمط تصفحك — أي مواقع ترتبط بأخرى

هذا كافٍ لبناء ملف تصفّح مفصّل. الحركة المشفّرة نفسها معتمة، لكن الوجهات ليست. ISP يعرف ماذا تتصفح دون أن يرى المحتوى أبداً.

في البلدان التي تحتفظ بسجلات استعلامات DNS افتراضياً (المملكة المتحدة بموجب Investigatory Powers Act، فرنسا بموجب Loi Renseignement، وآخرين)، التسريبات تصبح سجلات طويلة الأمد. نافذة الاحتفاظ تختلف؛ وجود السجلات لا يختلف.

كيف يمنع Fexyn التسريبات على Windows

خدمة helper الخاصة بـ Fexyn تثبّت دفاعاً متعدد الطبقات:

قواعد Name Resolution Policy Table (NRPT). NRPT يعمل على مستوى نظام التشغيل، قبل أن يرى أي تطبيق طلب DNS. Fexyn يثبّت قواعد NRPT شاملة تجبر كل بحث دومين عبر resolver VPN. NRPT يتجاوز إعدادات DNS لكل محوّل، التكوينات اليدوية، وSMHNR. هو القفل على مستوى نظام التشغيل لتوجيه DNS.

تكوين DNS لكل بروتوكول. كل بروتوكول VPN (WireGuard، VLESS Reality، OpenVPN) مكوّن بمسار DNS خاص به. WireGuard يستخدم AllowedIPs الشامل. VLESS يستخدم tun2socks مع تجاوز DNS النفق. OpenVPN يدفع DNS عبر dhcp-option DNS. كل الثلاثة يتقاربون على resolver VPN.

Null-routing لـ IPv6. عندما يكون VPN نشطاً، Fexyn يفعل null-route لحركة IPv6. بدلاً من الأمل أن IPv6 يأخذ النفق (أحياناً لا يفعل)، كل حركة IPv6 توجَّه إلى وجهة null محلية. هذا يلغي مسار تسرّب IPv6 بالكامل. اتصال IPv4 عبر النفق غير متأثر.

Windows Filtering Platform kill switch. إذا انقطع النفق، فلاتر WFP تحجب كل حركة لا-نفقية — بما فيها DNS. لا يوجد نافذة تسرّب أثناء إعادة الاتصال.

التركيبة تعالج SMHNR (NRPT يتجاوزه)، سقوط IPv6 (null-routed)، وتسريبات انقطاع النفق (WFP يحجب). DoH في المتصفح متروك وحده — هو اختيار المستخدم استخدام resolver DoH عام أو الخاص بـ VPN.

ماذا تفعل إذا كنت تتسرّب

إذا أظهر الاختبار تسريبات، اعمل من خلال هذا بترتيب:

أعد الاتصال بـ VPN. أبسط إصلاح. قواعد NRPT تنحرف أحياناً بعد دورات sleep/resume أو بعد تحديث Windows. اتصال جديد يعيد تطبيقها.
جرّب بروتوكولاً مختلفاً. بدّل إلى Fexyn Stealth (VLESS Reality) أو Fexyn Secure (OpenVPN). كل واحد له مسار DNS مختلف؛ إذا كان واحد مكوّن خطأً لشبكتك، آخر قد لا يكون.
جرّب خادماً مختلفاً. بعض resolvers الخوادم أبطأ؛ إذا كان resolver يُسقط استعلامات، نظام التشغيل قد يعود إلى resolver النظام.
افحص عملاء VPN آخرين يعملون. Cloudflare WARP، NordVPN's Meshnet، Tailscale، عملاء VPN للشركات — VPN متعددة تثبّت قواعد NRPT متنافسة وتقاتل بعضها. أوقف (لا تنفصل فقط) أي VPN آخر.
عطّل DoH المتصفح مؤقتاً. إذا كنت تريد كل DNS أن يتدفق عبر النفق لأغراض الاختبار، أوقف DoH على مستوى المتصفح لجلسة الاختبار.

دليل استكشاف الأخطاء الكامل في صفحة الدعم.

قراءة ذات صلة

جرّب Fexyn مجاناً لمدة 7 أيام. قفل DNS على افتراضياً؛ لا تحتاج لتفعيله.