تسريبات WebRTC: كيف يسلّم متصفحك IP الحقيقي خاصتك
تتصل بـ VPN. شريط الحالة يقول إنك محمي. تفتح موقعاً. الموقع يطلب بصمت من متصفحك عنوان IP الحقيقي خاصتك — ليس الخاص بـ VPN، بل ذلك الذي خصصه ISP فعلاً. المتصفح يعطيه. لا ترى prompt، لا ترى تحذيراً، وVPN يفعل بالضبط ما وعد به.
هذا تسرّب WebRTC. المتصفح هو المذنب، ليس VPN. ويعمل في كل متصفح حديث حتى تعطّله.
ما هو WebRTC
WebRTC (Web Real-Time Communication) هو browser API يوفّر الصوت والفيديو في المتصفح. Google Meet، قنوات Discord الصوتية، Slack huddles، Whereby، الجزء داخل المتصفح من Zoom — جميعهم يستخدمون WebRTC. كذلك تحويلات الملفات المباشرة، screen sharing، وأزرار "اضغط للاتصال" على صفحات الدعم.
لكي تعمل اتصالات peer-to-peer، يحتاج المتصفح معرفة IP العام خاصتك. هكذا يصلك الطرف الآخر. WebRTC يحلّ هذا عبر STUN server: المتصفح يسأل خادم STUN عام "من أي عنوان جئت إليك؟". خادم STUN يرد بـ IP الذي يراه. المتصفح يخزّنه ويعطيه لأي صفحة تسأل عبر WebRTC API.
البنية كانت منطقية في 2011، عندما صُمّم WebRTC. peer-to-peer حساس للـ latency كان حالة الاستخدام. الخصوصية من المواقع العشوائية لم تكن في وثيقة التصميم.
لماذا VPN لا يصلح هذا
VPN ينفق حركة شبكتك. تبادل STUN لـ WebRTC يعمل فوق ذلك، لكن الرد الذي يخزّنه المتصفح هو IP الحقيقي خاصتك، ليس النفقي، في حالتين:
الحالة 1: STUN طُلب قبل توصيل VPN. المتصفح تعلّم IP الحقيقي خاصتك عند البدء أو في شبكة سابقة. خزّنه. الصفحة تطلب عناوين IP من WebRTC وتحصل على القيمة الحقيقية المخزّنة.
الحالة 2: VPN لا ينفق UDP إلى خادم STUN. في بعض تكوينات VPN يوجد edge-cases في التوجيه. حزمة STUN تخرج من النفق.
حتى مع VPN منفّق بشكل صحيح، STUN cache على مستوى المتصفح هو سطح هجوم. الصفحات لا تحتاج لطلب STUN بنفسها؛ هي فقط تطلب من WebRTC عناوين IP التي يعرفها المتصفح بالفعل.
Exposed مقابل leaking
المصطلحات تهم لأن التفاعل مختلف.
Exposed. لست على VPN، تفتح صفحة، الصفحة ترى IP الحقيقي خاصتك. هذا سلوك متوقع. ليس تسرّباً، هو الإنترنت يعمل كما صُمّم.
Leak (تسرّب). أنت على VPN، الصفحة يجب أن ترى فقط IP الخاص بـ VPN، لكن WebRTC لا يزال يعطي IP الحقيقي خاصتك. هذا تسرّب. الخصوصية التي ظننت أنك تملكها مكسورة.
اختبار تسرّب WebRTC من Fexyn يُظهر في أي حالة أنت. مع VPN متصل، IP العام الذي يظهر يجب أن يكون IP خادم Fexyn. إذا كان IP منزلك — أنت تتسرّب.
ماذا يرى مهاجم من تسرّب
نفس الشيء الذي يراه بدون VPN:
- IP العام الحقيقي خاصتك
- جغرافية تقريبية (عادةً للمدينة، أحياناً للحي لمزودي residential)
- ISP خاصتك
- معرّف ثابت يمكن ربطه بزيارات أخرى ومواقع أخرى
أسوأ من بدون VPN: التسرّب يعطيهم كلاً من IP الحقيقي خاصتك وIP الخاص بـ VPN. يستطيعون ربطها عبر الجلسات، بناء ملف يتبعك سواء كان VPN مرفوعاً أم لا، واستخدام IP الخاص بـ VPN نفسه كـ fingerprint.
لنماذج التهديد حيث الجغرافية تهم — الصحفيون، الناشطون، أي شخص يختبئ من ملاحق، أي شخص يستخدم VPN لتجنّب التتبع الخاص باختصاص — تسرّب WebRTC يلغي الحماية بصمت.
إصلاحات حسب المتصفح
العلاج يعيش في المتصفح، ليس في VPN. كل متصفح يعالج WebRTC بشكل مختلف.
Firefox — تعطيل كامل
أنظف خيار. Firefox يسمح بتعطيل WebRTC بالكامل:
- افتح علامة تبويب جديدة واذهب إلى
about:config. اقبل التحذير. - ابحث عن
media.peerconnection.enabled. - اجعله
false. - أعد تشغيل Firefox.
التكلفة: مكالمات الفيديو في أي تطبيقات قائمة على المتصفح تتوقف عن العمل. Slack huddles، Google Meet، Discord voice في المتصفح — ميتة حتى تعيدها. لمعظم المستخدمين الذين يركزون على الخصوصية، هذا مقبول؛ المكالمات تتم في تطبيق سطح المكتب.
Brave — toggle مدمج
Brave يأتي مع إعداد موجّه للخصوصية:
- افتح
brave://settings. - ابحث عن "WebRTC".
- اضبط "WebRTC IP Handling Policy" على Disable non-proxied UDP.
هذا أقوى إعداد لا يكسر WebRTC تماماً. المكالمات تعمل؛ حركة STUN محدودة عبر مسار proxy. لمستخدمي Brave على VPN — الإعداد الصحيح.
Chrome وEdge — تحتاج extension
لا Chrome ولا Edge لديهما WebRTC toggle مدمج في UI الإعدادات. تحتاج extension. ثبّت أحد:
- uBlock Origin مع فلتر "Prevent WebRTC from leaking local IP addresses" مفعّل. uBlock Origin هو ad-blocker الصحيح على أي حال؛ هذه مكافأة مجانية.
- WebRTC Network Limiter (مُنشَر بواسطة Google نفسها). single-purpose، يقيّد WebRTC على مسار proxy.
تجنّب extensions "WebRTC fix" العشوائية بنجمة واحدة في Chrome Web Store. الفئة تجذب extensions منخفضة الجودة وأحياناً خبيثة. التزم بـ uBlock Origin أو ما من Google.
Safari
Safari يطبّق WebRTC لكن لا يكشف toggle. إذا كنت في Safari وتسريبات WebRTC تقلقك — انتقل إلى Brave (Webkit-based، لديه toggle) أو Firefox (Gecko-based، تعطيل كامل).
كيف يتعامل Fexyn مع هذا
Fexyn لا يحاول monkey-patch متصفحك. سلوك WebRTC في المتصفح هو مستوى المتصفح، وخارج ما يستطيع VPN أو يجب أن يتجاوزه.
ما يفعله Fexyn:
- ينفّق كل حركة UDP، بما فيها STUN، عندما يسمح البروتوكول. WireGuard ينفّق كل شيء افتراضياً. تكوينات VLESS Reality وOpenVPN تنفّق UDP عبر نفس المسار.
- يوصي بإعدادات متصفح محددة على صفحة الدعم.
- يوفّر أداة فحص، حتى تستطيع التحقق من تركيبة متصفح/إعداد محددة.
التركيبة — نفق STUN عبر VPN بالإضافة إلى WebRTC معطّل أو مقيّد على جانب المتصفح — تغلق التسرّب.
أعد الاختبار بعد الإصلاح
بعد تغيير إعدادات المتصفح، أعد تشغيل المتصفح وشغّل الاختبار مرة أخرى على fexyn.com/tools/webrtc-leak-test. IP العام الذي يظهر يجب أن يطابق خادم Fexyn. IP المحلي يجب أن يكون إما فارغاً أو يُظهر فقط عنوان محوّل نفق VPN.
إذا كنت لا تزال ترى IP العام الحقيقي خاصتك، التغيير لم يُطبَّق. تحقق من:
- المتصفح أُعيد تشغيله فعلاً (إغلاق علامات التبويب لا يكفي؛ اخرج من التطبيق)
- لـ Brave الإعداد "Disable non-proxied UDP"، ليس "Disable non-proxied UDP and force proxy"
- لـ Chrome/Edge الـ extension مفعّل، ليس فقط مثبّت
ما ليس عليه تسرّب WebRTC
تسريبات WebRTC تتعلق تحديداً بكشف IP عبر browser API. لا:
- تؤثر على تطبيقات غير المتصفح. تطبيق سطح مكتب أصلي على VPN ليس له هذه المشكلة.
- تؤثر على تطبيقات الموبايل التي لها شبكتها الخاصة. تطبيقات iOS/Android التي لا تضمّن webview عادةً لا تكشف IP الخاص بـ VPN عبر WebRTC.
- تشير إلى أن نفق VPN نفسه مكسور. النفق بخير؛ المتصفح يسلّم المعلومات طوعاً فوق مستوى النفق.
قراءة ذات صلة
- اختبار تسرّب WebRTC
- اختبار تسرّب DNS
- إصلاح تسرّب WebRTC
- كيف تكشف تسريبات DNS الموقع
- ما يراه ISP بدون VPN
جرّب Fexyn مجاناً لمدة 7 أيام. النفق يفعل جزءه؛ إصلاحات المتصفح إعداد لمرة واحدة.