تسرّبات VPN موضّحة: كيف تختبر فعلاً تسرّبات DNS وWebRTC وIPv6
تسرّبات VPN موضّحة: تسرّبات DNS وWebRTC وIPv6 (وكيف تختبرها فعلاً)
يقول تطبيق VPN لديك متصل. تبدو هذه الكلمة الواحدة وكأنها ضمان، لكنها لا تعني سوى أن جهازك قد أنشأ نفقاً مشفّراً إلى خادم VPN. وهي لا تقول شيئاً عمّا إذا كانت كل قطعة من حركة المرور التي تكشف هويتك تستخدم فعلاً هذا النفق. هناك ثلاثة أنماط شائعة من الأعطال — تسرّبات DNS، وتسرّبات WebRTC، وتسرّبات IPv6 — وكل واحد منها قادر على كشف عنوان IP الحقيقي أو نشاط تصفّحك بينما يجلس التطبيق هناك عارضاً علامة صح خضراء تبعث على الطمأنينة.
يقوم هذا الدليل بثلاثة أشياء لا تفعلها أبداً الصفحات التي تركّز على تسرّب واحد وتدفعك لشراء VPN معيّن. أولاً، يشرح الآلية الفعلية وراء كل تسرّب لكي تفهم لماذا يمكن لـ VPN متصل أن يخونك رغم ذلك. ثانياً، يرشدك خلال اختبار ذاتي باستخدام أدوات مجانية ومستقلة لا يتعيّن عليك أن تثق بمزوّد للحصول عليها. ثالثاً، يمنحك الإصلاحات الدقيقة لكل نظام تشغيل ومتصفّح وراوتر — وانضباط إعادة الاختبار الذي يؤكّد أن الإصلاح صمد. لا ترويج لعلامة تجارية، ولا روابط إحالة، فقط الآليات.
ما هو تسرّب VPN فعلاً
التسرّب هو أي حركة مرور يُفترض أن تنتقل عبر النفق المشفّر لكنها تخرج بدلاً من ذلك عبر اتصالك العادي بالإنترنت، كاشفةً معلومات كان من المفترض أن يخفيها الـ VPN. التسرّبات الثلاثة في هذا الدليل تكشف شيئين مختلفين. يكشف تسرّب DNS المواقع التي تبحث عنها لمزوّد خدمة الإنترنت لديك (أو لمن يُشغّل المُحلِّل الذي تستخدمه بالخطأ). أما تسرّب WebRTC وتسرّب IPv6 فيمكنهما كشف عنوان IP الحقيقي — موقعك وهويتك الفعليين على الإنترنت — مباشرةً للمواقع التي تزورها.
أهم شيء يجب فهمه منذ البداية: هذه مشكلات منفصلة بأسباب منفصلة وإصلاحات منفصلة. ينفِّس المنافسون عن هذا لأنه غير مريح لسردية مبيعات بنقرة واحدة، لكنه جوهر اللعبة كله. يمكنك سدّ تسرّب DNS وتظلّ تُسرّب عنوان IP عبر WebRTC. ويمكنك تحصين WebRTC في متصفّحك وتظلّ تُسرّب عبر IPv6. إغلاق واحد لا يخبرك بشيء عن الاثنين الآخرين. لهذا فإن اختبار التسرّب الحقيقي يفحص الثلاثة جميعاً، في كل مرة.
كيف يحدث كل تسرّب (الآلية)
تسرّبات DNS: عمليات بحث تهرب من النفق
قبل أن يُحمّل جهازك example.com، يطلب من مُحلِّل DNS أن يترجم ذلك الاسم إلى عنوان IP. عندما يكون الـ VPN مُهيّأً بشكل صحيح، ينتقل استعلام DNS ذاك داخل النفق إلى مُحلِّل يتحكّم فيه الـ VPN. يحدث تسرّب DNS عندما يذهب الاستعلام بدلاً من ذلك إلى مُحلِّل مزوّد خدمة الإنترنت لديك (أو مُحلِّل يدفعه راوترك) عبر الاتصال المكشوف. ورغم أن محتوى الصفحة قد يظلّ يتدفّق عبر النفق، فإن عملية البحث نفسها تكشف كل نطاق تزوره لطرف ثالث — وتربطه بعنوان IP الحقيقي.
المتسبّبون المعتادون هم نظام تشغيل يتجاهل إعدادات DNS الخاصة بالـ VPN، أو مُحلِّل مُثبَّت يدوياً (مثل 8.8.8.8 أو 1.1.1.1 مضبوط يدوياً) يتجاوز النفق، أو قواعد النفق المنقسم التي توجّه DNS خارج الـ VPN. على نظام Windows تحديداً، هناك ميزة تُسمّى حلّ الأسماء الذكي متعدّد المنازل (smart multi-homed name resolution) يمكنها إطلاق استعلامات DNS من كل واجهة شبكة في آنٍ واحد واستخدام أيّها يردّ أولاً — وغالباً ما يكون مزوّد خدمة الإنترنت لديك.
تسرّبات WebRTC: المتصفّح يسلّم عنوان IP الخاص بك
WebRTC (التواصل في الزمن الحقيقي عبر الويب) هي تقنية المتصفّح التي تقف وراء مكالمات الفيديو داخل الصفحة، والدردشة الصوتية، ونقل الملفات من نظير إلى نظير. لربط نظيرين مباشرةً، يحتاج WebRTC إلى اكتشاف عناوين IP الخاصة بالجهاز نفسه. يفعل ذلك عبر خوادم STUN التي تردّ على المتصفّح بعنوان IP العام الذي تراه، كما يُعدّد عناوين الشبكة المحلّية. وبإمكان صفحة ويب قراءة هذه المرشّحات ICE عبر واجهة برمجة JavaScript — دون أي نافذة إذن ودون أن تنقر على أي شيء.
وهنا المأزق الذي يجعل WebRTC خطيراً حتى مع VPN يعمل: يمكن أن يحدث هذا الاكتشاف خارج مسار البروكسي الذي يستخدمه متصفّحك لتحميل الصفحات العادي. وقد ينتهي الأمر بالصفحة وهي ترى عنوان IP العام الذي يعتبره نظام تشغيلك حقيقياً، والذي قد يكون عنوانك الفعلي بدلاً من عنوان الـ VPN. تسرّب WebRTC هو مشكلة متصفّح. ولا يُصلَح بإعدادات DNS الخاصة بالـ VPN ولا بمفتاح الإيقاف فيه، وهذا بالضبط سبب ذهول الناس الذين أصلحوا تسرّب DNS لديهم حين يجدون عنوان IP لا يزال ظاهراً.
تسرّبات IPv6: حركة مرور على طريق لم يعبّده النفق قطّ
كثير من أنفاق VPN تحمل حركة IPv4 فقط. وإذا كان مزوّد خدمة الإنترنت وشبكتك المنزلية يوفّران أيضاً اتصال IPv6 — وهو ما أصبح الوضع الافتراضي بشكل متزايد — فإن أي طلب إلى وجهة تدعم IPv6 يمكن أن ينتقل عبر اتصال IPv6 الأصلي لديك، خارج النفق الذي يدعم IPv4 فقط تماماً. فيرى الموقع عنوان IPv6 الحقيقي الخاص بك. ولم يلمس الـ VPN تلك الحركة قطّ، وغالباً لم يلاحظها أصلاً، لأنه كان يراقب جانب IPv4 فحسب.
لهذا السبب يكون تسرّب IPv6 شائعاً بهذا الهدوء: لا شيء يتعطّل، ولا شيء يبدو خاطئاً، ويُبلِّغ الـ VPN عن النجاح. الإصلاح هو إمّا تعطيل IPv6 على الجهاز أو الشبكة، أو استخدام VPN ينفّق IPv6 صراحةً أو يحجبه أثناء الاتصال. والأمل في أن يتولّى مزوّدك الأمر بصمت ليس استراتيجية — بل تختبره.
أجرِ الاختبار: أدوات مجانية وكيف تقرأها
استخدم أدوات مستقلة من طرف ثالث بدلاً من صفحة 'عنوان IP مخفي' التي يعرضها لك مزوّد VPN — فلدى المزوّد كل الدوافع للإبلاغ عن النجاح. أجرِ كل اختبار والـ VPN متصل، في المتصفّح نفسه وعلى الجهاز نفسه الذي تستخدمه فعلاً. وكخط أساس، يجدر بك تشغيلها مرة واحدة والـ VPN مُطفأ أولاً لتعرف كيف يبدو عنوان IP الحقيقي ومزوّد خدمتك؛ ثم شغّل الـ VPN وتأكّد من اختفاء تلك القيم.
الخطوة 1 — اختبار تسرّب DNS
افتح dnsleaktest.com وأجرِ الاختبار الموسّع (Extended test). يُحمّل سلسلة من أسماء المضيفين الفريدة ويُبلِّغ عن خوادم DNS التي حلّتها. النتيجة النظيفة تُظهر مُحلِّلات تخصّ مزوّد VPN لديك (أو مُحلِّل خصوصية يستخدمه الـ VPN)، والأهم أنها لا تُدرج اسم مزوّد خدمة الإنترنت ولا بلدك الأصلي إذا اتصلت بخادم في مكان آخر. أما النتيجة المُسرِّبة فتُظهر مُحلِّل مزوّد خدمتك، أو خوادم في موقعك الحقيقي لم تتوقّعها. ويعرض ipleak.net المعلومات نفسها عن DNS إلى جانب عنوان IP الخاص بك، وهو أمر مفيد للتحقّق المتقاطع.
الخطوة 2 — اختبار تسرّب WebRTC
افتح browserleaks.com/webrtc. انظر إلى عنوان IP العام (Public IP Address) الذي يكتشفه عبر WebRTC. النتيجة النظيفة تُظهر إمّا لا عنوان IP عام، أو عنوان خادم الـ VPN فقط. أما النتيجة المُسرِّبة فتُظهر عنوان IP العام الحقيقي الخاص بك في قسم WebRTC رغم أن ترويسة الصفحة (التي تستخدم طلب HTTP عادياً) تُظهر عنوان الـ VPN — وهذا التضارب هو التوقيع الكلاسيكي لتسرّب WebRTC. أما العناوين المحلّية في نطاقات 10.x أو 172.16–31.x أو 192.168.x أو نطاق mDNS بصيغة .local فهي غير ضارّة عموماً؛ الخطر الحقيقي هو ظهور عنوان IP العام الأصلي الخاص بك.
الخطوة 3 — اختبار IPv6 وعنوان IP الإجمالي
افتح ipleak.net. يعرض عنوان IPv4 الخاص بك، وأي عنوان IPv6، وخوادم DNS لديك في صفحة واحدة. النتيجة النظيفة تُظهر عنوان الـ VPN فقط (مطابقاً للبلد الذي اخترته) وإمّا لا عنوان IPv6 أو عنوان IPv6 يخصّ الـ VPN أيضاً. أما النتيجة المُسرِّبة فتُظهر عنوان IPv6 من مزوّد خدمة الإنترنت لديك، أو زوجاً من IPv4/IPv6 يشيران إلى موقعين مختلفين. وإذا رأيت عنوان IPv6 حقيقياً إلى جانب عنوان IPv4 للـ VPN، فذلك تسرّب IPv6 نموذجي بامتياز.
الـ VPN الذي يُخفي عنوان IPv4 لكنه يكشف عنوان IPv6 لم يحمِك نصف حماية — فبالنسبة لأي موقع يدرك IPv6، أنت ببساطة لا تستخدم VPN على الإطلاق.
الإصلاحات الدقيقة لكل نظام تشغيل ومتصفّح وراوتر
إصلاح تسرّبات DNS
في تطبيق VPN: فعّل أي خيار من نوع 'استخدام DNS الخاص بالـ VPN فقط'، أو 'الحماية من تسرّب DNS'، أو 'حجب DNS غير الخاص بالـ VPN'. كثير من التطبيقات تفعّله افتراضياً، لكن إعدادات OpenVPN/WireGuard من أطراف ثالثة كثيراً ما لا تفعل ذلك.
Windows: عطّل حلّ الأسماء الذكي متعدّد المنازل، الذي يُبعثر DNS عبر الواجهات. على Windows Pro يمكنك ضبط سياسة المجموعة 'Turn off smart multi-homed name resolution' على Enabled؛ وإلا فاختر عميل VPN يضبط DNS ويحجب المُحلِّلات الأخرى. أزل أي DNS عام مُهيّأ يدوياً (8.8.8.8، 1.1.1.1) من محوّلاتك أثناء الاختبار.
macOS / Linux: تأكّد من عدم وجود مُحلِّل مُثبَّت يدوياً في إعدادات الشبكة أو في
/etc/resolv.confيتجاوز النفق؛ ودع عميل الـ VPN يدير DNS. على Linux مع systemd-resolved، تأكّد من أن الـ VPN يضبط مسار نطاق (domain route) كي تذهب الاستعلامات إلى مُحلِّله.الراوتر: إذا كنت تُشغّل الـ VPN على الراوتر، اضبط DNS الخاص بالراوتر على مُحلِّل الـ VPN وعطّل أي DNS مُعيَّن من مزوّد خدمة الإنترنت. وعطّل أيضاً ميزات الراوتر التي تعترض DNS أو تعيد توجيهه (بعض إعدادات 'الرقابة الأبوية' أو 'الحماية من إعادة ربط DNS').
إصلاح تسرّبات WebRTC (في المتصفّح فقط)
Firefox: اكتب
about:configفي شريط العنوان، واقبل التحذير، وابحث عنmedia.peerconnection.enabled، واضبطه علىfalse. هذا يُعطّل WebRTC بالكامل. إذا كنت تحتاج WebRTC للمكالمات، فاتركه مُفعّلاً لكن اعتمد على VPN/إضافة تُخفي عنوان IP المُكتشَف، ثم أعد الاختبار.Chrome / Edge: لا يوجد مفتاح مدمج لتعطيل WebRTC بالكامل. انتبه إلى أن خيار uBlock Origin القديم 'Prevent WebRTC from leaking local IP addresses' قد أُزيل من إضافة سطح المكتب منذ عام 2021، وحتى حين كان موجوداً فقد كان يُخفي العناوين المحلّية/الشبكة المحلّية فحسب — ولم يوقف قطّ كشف عنوان IP العام الذي يكشفك فعلاً، فلم يكن قطّ الإصلاح الذي افترضه الناس. أنظمة Chromium الحديثة تُخفي بالفعل عناوين IP المحلّية باستخدام mDNS (يمكنك التحقّق من علامة 'Anonymize local IPs exposed by WebRTC' عند
chrome://flags). وللتحكّم في كشف عنوان IP العام، استخدم إضافة مخصّصة للتحكّم في WebRTC ثم تحقّق عبر اختبار تسرّب، لأن الإضافات تتفاوت في مدى اكتمال حجبها له.Safari: كشف WebRTC أكثر محدودية افتراضياً، لكن اختبره مع ذلك. يمكنك تعطيله عبر ميزات WebRTC/التجريبية في قائمة Develop إذا لم تكن بحاجة إليه.
تحقّق من الواقع: قد يؤدّي تعطيل WebRTC إلى تعطيل Google Meet وDiscord في المتصفّح وJitsi وأدوات مماثلة. إذا كنت تحتاجها، فالمسار العملي هو متصفّح/إضافة تُسلّم عنوان الـ VPN فقط بدلاً من إيقاف WebRTC نهائياً — على أن يُؤكَّد ذلك بإعادة الاختبار.
إصلاح تسرّبات IPv6
أفضل خيار: استخدم VPN يوفّر صراحةً حماية من تسرّب IPv6 (يحجب IPv6 أو ينفّقه أثناء الاتصال). فعّل ذلك الإعداد وأعد الاختبار.
Windows: عطّل IPv6 على المحوّل النشط (خصائص محوّل الشبكة، وأزل علامة الاختيار عن Internet Protocol Version 6)، أو استخدم حجب IPv6 الخاص بالـ VPN. أعد تفعيله حين تتوقّف عن استخدام VPN لا يستطيع التعامل معه.
macOS: في إعدادات النظام، اضبط Configure IPv6 لخدمة الشبكة على Link-local only (أو Off عبر سطر الأوامر) إذا كان الـ VPN لا يستطيع تنفيقه.
Linux: عطّل IPv6 لكل واجهة على حدة أو على مستوى النظام بأكمله عبر
sysctl(على سبيل المثالnet.ipv6.conf.all.disable_ipv6=1) إذا كان النفق يدعم IPv4 فقط.الراوتر: إذا كنت تُشغّل الـ VPN على الراوتر، عطّل IPv6/WAN IPv6 الخاص بالراوتر كي لا يستطيع أي جهاز على الشبكة التسرّب عبره. هذا أنظف إصلاح لمنزل بأكمله.
لماذا يظلّ الـ VPN 'المتصل' يُسرّب
حتى بعد أن تجتاز الاختبارات الثلاثة مرة واحدة، الحماية ليست دائمة — بل هي حالة يمكن أن تتعطّل بصمت. هذه هي اللحظات التي يبدأ فيها الـ VPN 'المتصل' بالتسرّب بهدوء:
تغيّرات الشبكة: الانتقال من Wi-Fi إلى Ethernet، أو تبديل نقاط الوصول، أو تنقّل هاتفك بين Wi-Fi والبيانات الخلوية، يمكن أن يوجّه حركة المرور لحظياً خارج النفق قبل أن يعيد الـ VPN ترسيخ قواعده.
النوم والاستيقاظ: حين يستيقظ حاسوب محمول من النوم، غالباً ما تعود الشبكة قبل أن يعيد الـ VPN الاتصال. ولبضع ثوانٍ، تستخدم حركة المرور الاتصال المكشوف — وهي مدة كافية لتطبيقات الخلفية كي ترسل بياناتها بعنوان IP الحقيقي.
إعادات الاتصال والانقطاعات: في أي وقت ينقطع فيه النفق ويعيد الاتصال، تكون هناك نافذة يمكن أن تهرب فيها حركة المرور ما لم يحجبها مفتاح إيقاف.
البوّابات الأسيرة: تتطلّب شبكات Wi-Fi في الفنادق والمطارات والمقاهي تحميل صفحة تسجيل دخول قبل أن يعمل الإنترنت. تلك الصفحة تُحمّل خارج الـ VPN بحكم التصميم، وتظلّ بعض الإعدادات مُسرِّبة حتى تعيد الاتصال يدوياً بعد ذلك.
النفق المنقسم: إذا كنت قد استثنيت تطبيقات معيّنة — أو DNS — من الـ VPN، فتلك الاستثناءات تسرّبات بحكم الإعداد. تحقّق مرتين من أن DNS ليس مدرجاً بهدوء في قائمة 'التجاوز'.
عودة IPv6: قد يؤدّي تحديث نظام التشغيل أو إعادة ضبط الشبكة إلى إعادة تفعيل IPv6 الذي عطّلته سابقاً بصمت، فيُعيد فتح ذلك المسار دون تحذير.
مفاتيح الإيقاف وإعدادات الحماية من التسرّب — وكيف تفشل بصمت
مفتاح الإيقاف (kill switch) هو شبكة أمان لمشكلة الانقطاع وإعادة الاتصال: حين يسقط النفق، يحجب كل حركة مرور الإنترنت حتى يعود الـ VPN، فلا يهرب شيء في الفجوة. أما الحماية المدمجة من التسرّب (الحماية من تسرّب DNS، وحجب IPv6، وميزات قفل الشبكة) فتفرض أن يستخدم DNS وIPv6 النفق فقط على الدوام. فعّل كليهما — فهما يتولّيان نوافذ الفشل التي لا يمكنك مراقبتها يدوياً.
لكن افهم أنماط فشلهما الصامتة. لا يتحرّك مفتاح الإيقاف إلا حين يكتشف التطبيق أن النفق قد سقط؛ فإذا كان النفق قائماً تقنياً لكن DNS أو IPv6 يُسرّب من حوله، فإن مفتاح الإيقاف لا يرى مشكلة ولا يفعل شيئاً. ومفاتيح الإيقاف على مستوى التطبيق تحمي حركة مرور تطبيق الـ VPN نفسه فقط، لا النظام بأكمله. وبعض مفاتيح الإيقاف لا تعمل أثناء نافذة النوم/الاستيقاظ أو قبل تسجيل الدخول عند الإقلاع. ومفتاح الإيقاف من 'نمط الجدار الناري' الذي يحجب حركة المرور بالكامل حين يكون مُطفأً قد يُخلَط بينه وبين انقطاع الإنترنت، مما يُغري الناس بتعطيله. الدرس: مفتاح الإيقاف يقلّل الخطر، لكنه لا يحلّ محلّ الاختبار. الدليل الوحيد على أن إعداداتك تعمل هو اختبار ناجح.
نتيجة غير ضارّة مقابل فشل حقيقي في الخصوصية
ليس كل مُدخَل غير مألوف على صفحة اختبار التسرّب كارثة. معرفة الفرق تمنعك من مطاردة أشباح — أو من تجاهل تعرّض حقيقي.
غير ضارّ: أن يُظهر WebRTC عناوين محلّية/خاصة فقط (10.x، 172.16–31.x، 192.168.x) أو اسم مضيف mDNS بصيغة
.local. هذه لا تُعرّف عنك لموقع ويب.غير ضارّ: مُحلِّلات DNS تخصّ مزوّد VPN لديك أو مُحلِّل خصوصية يستخدمه، حتى لو كانت في مدينة مختلفة عن خادم الـ VPN — فالمزوّدون يُشغّلون أساطيل من المُحلِّلات.
غير ضارّ: لا عنوان IPv6 على الإطلاق حين تكون قد عطّلت IPv6. هذا هو الهدف، وليس فشلاً.
فشل حقيقي: أي اختبار يُظهر عنوان IP العام الحقيقي الخاص بك (IPv4 أو IPv6)، أو مدينتك/مزوّد خدمتك الحقيقي، أو بلدك الأصلي حين اتصلت عمداً بمكان آخر.
فشل حقيقي: نتائج DNS تُسمّي مزوّد خدمة الإنترنت الفعلي لديك، أو عنوان IPv4 وعنوان IPv6 يُحلّان إلى موقعين مختلفين.
فشل حقيقي: أن تُظهر ترويسة الصفحة عنوان الـ VPN بينما يُظهر قسم WebRTC عنوانك الحقيقي — التضارب هو التسرّب.
قاعدة عامة: ظهور عنوان IP عام أو اسم مزوّد خدمتك حيث لا ينبغي هو فشل حقيقي. أما العناوين الخاصة/المحلّية والمُحلِّلات المملوكة للمزوّد فهي ضوضاء.
انضباط إعادة الاختبار: العادة التي تحميك فعلاً
اختبار التسرّب لقطة لحظية، لا شهادة. وبما أن الحالة الواقية تتعطّل عند تغيّرات الشبكة، والنوم، وإعادات الاتصال، والبوّابات الأسيرة، فإن الاختبار لا يكون ذا معنى إلا للظروف التي اختبرت تحتها. ابنِ هذه العادة:
أعد الاختبار بعد كل إصلاح — غيّر إعداداً واحداً، ثم تأكّد من إغلاق ذلك التسرّب المحدّد قبل المضيّ قدماً. إصلاح الثلاثة دفعةً واحدة والاختبار مرة واحدة يُخفي أي تغيير نجح.
أعد الاختبار بعد كل تغيّر في الشبكة — شبكة Wi-Fi جديدة، أو التبديل إلى البيانات الخلوية، أو توصيل Ethernet، أو بعد تسجيل الدخول عبر بوّابة أسيرة.
أعد الاختبار بعد الاستيقاظ من النوم وبعد إعادة اتصال الـ VPN، لأنهما النافذتان الأعلى خطورة.
أعد الاختبار بعد تحديثات نظام التشغيل والتطبيقات، التي قد تعيد تفعيل IPv6 أو تعيد ضبط سلوك DNS بصمت.
شغّل الاختبارات الثلاثة معاً في كل مرة — فـ DNS وWebRTC وIPv6 مستقلّة، ونتيجة نظيفة على أحدها لا تخبرك بشيء عن الآخرين.
الخلاصة العملية
'متصل' نقطة بداية، لا دليل على الخصوصية. اختبر التسرّبات الثلاثة جميعاً بأدوات مستقلة — dnsleaktest.com لـ DNS، وbrowserleaks.com/webrtc لـ WebRTC، وipleak.net لـ IPv6 وعنوان IP الإجمالي. تعامل معها كمشكلات منفصلة: افرض DNS الخاص بالـ VPN على مستوى نظام التشغيل أو الراوتر، وحيّد WebRTC في المتصفّح، واحجب IPv6 أو نفّقه. فعّل مفتاح الإيقاف والحماية المدمجة من التسرّب للفجوات التي لا يمكنك مراقبتها، لكن لا تثق بهما بشكل أعمى أبداً. ثم أعد الاختبار بعد كل إصلاح وكل تغيّر في الشبكة. عشر دقائق من الاختبار تخبرك عن تعرّضك الحقيقي أكثر مما تخبرك به أي صفحة تسويقية لأي مزوّد.
الأسئلة الشائعة
ما هو اختبار تسرّب VPN وكيف أُجريه؟
اختبار تسرّب VPN يفحص ما إذا كانت أي حركة مرور تهرب من نفقك المشفّر وتكشف عنوان IP الحقيقي أو عمليات بحث DNS بينما الـ VPN متصل. أجرِه بأن تتصل بالـ VPN، ثم تزور أدوات مستقلة مثل dnsleaktest.com وbrowserleaks.com/webrtc وipleak.net. إذا أظهر أي منها عنوان IP العام الحقيقي، أو مزوّد خدمتك، أو موقعك الأصلي، فلديك تسرّب.
كيف يعمل اختبار تسرّب DNS وما الذي يُعدّ نجاحاً؟
اختبار تسرّب DNS يُحمّل أسماء مضيفين فريدة ويُبلِّغ عن خوادم DNS التي حلّتها. تنجح إذا كانت المُحلِّلات تخصّ مزوّد VPN لديك ولم يُدرَج مزوّد خدمة الإنترنت الخاص بك. وتفشل إذا ظهر مُحلِّل مزوّد خدمتك أو كانت الخوادم في موقعك الحقيقي بينما اتصلت بمكان آخر.
كيف أُصلح تسرّب DNS؟
فعّل أولاً 'الحماية من تسرّب DNS' أو 'استخدام DNS الخاص بالـ VPN فقط' في تطبيق VPN لديك. على Windows، عطّل أيضاً حلّ الأسماء الذكي متعدّد المنازل وأزل أي DNS عام مضبوط يدوياً مثل 8.8.8.8 من محوّلك. وعلى راوتر يُشغّل الـ VPN، وجّه DNS الخاص بالراوتر إلى مُحلِّل الـ VPN وعطّل DNS المُعيَّن من مزوّد خدمة الإنترنت، ثم أعد الاختبار.
ما هو تسرّب WebRTC وهل يوقفه الـ VPN لديّ؟
تسرّب WebRTC هو حين تكتشف ميزة التواصل في الزمن الحقيقي في متصفّحك عنوان IP الحقيقي وتكشفه لصفحة ويب، حتى مع اتصال الـ VPN. معظم شبكات VPN لا توقفه لأنه سلوك متصفّح، لا سلوك شبكة. أصلحه في Firefox بضبط media.peerconnection.enabled على false في about:config. أما Chrome وEdge فليس فيهما مفتاح مدمج لتعطيل WebRTC، لذا استخدم إضافة مخصّصة للتحكّم في WebRTC وأعد الاختبار — ولا تعتمد على خيار uBlock Origin القديم لعنوان IP المحلّي، الذي أُزيل من إضافة سطح المكتب ولم يحجب قطّ كشف عنوان IP العام أصلاً.
ما هو تسرّب IPv6 وكيف أمنعه على الـ VPN لديّ؟
يحدث تسرّب IPv6 حين يتجاهل نفق VPN الذي يدعم IPv4 فقط حركة IPv6، فيتركها تنتقل عبر اتصال مزوّد خدمتك وتكشف عنوان IPv6 الحقيقي الخاص بك. امنعه بتفعيل الحماية من تسرّب IPv6 في الـ VPN لديك، أو بتعطيل IPv6 على جهازك أو راوترك. بعد تغيير الإعداد، تأكّد على ipleak.net من عدم ظهور أي عنوان IPv6 من مزوّد خدمة الإنترنت.
هل يمنع مفتاح الإيقاف تسرّبات DNS وWebRTC؟
ليس بشكل موثوق. مفتاح الإيقاف لا يحجب حركة المرور إلا حين يكتشف أن النفق قد سقط، فلا يفعل شيئاً حيال تسرّبات DNS أو WebRTC التي تحدث بينما النفق لا يزال قائماً. أنت بحاجة إلى حماية منفصلة من تسرّب DNS وتحصين WebRTC على جانب المتصفّح، مع مفتاح الإيقاف كخطّ دفاع احتياطي لإعادات الاتصال والانقطاعات.
كم مرة ينبغي أن أُجري اختبار تسرّب VPN؟
اختبر بعد كل تغيير في الإعداد، وأعد الاختبار بعد كل تغيّر في الشبكة، ودورة نوم/استيقاظ، وإعادة اتصال للـ VPN، وتسجيل دخول عبر بوّابة أسيرة، وتحديث كبير لنظام التشغيل أو التطبيق. كل لحظة من هذه اللحظات قد تعيد فتح تسرّب بصمت. وشغّل دائماً الاختبارات الثلاثة معاً، لأن DNS وWebRTC وIPv6 مشكلات مستقلّة.
