فحص درجة التخفي للبروكسي: اختبار تمويه VPN وتسريب الخصوصية

لأن المعلومتين تأتيان من طبقتين مختلفتين، ويمكن تزييف إحداهما فقط من داخل المتصفح. سلسلة User-Agent هي مجرد نص سطحي يمكن لأي متصفح أو إضافة تغييره. أما حزمة TCP SYN التي تفتح الاتصال، فتُبنى بواسطة نواة نظام التشغيل، ويختلف ترتيب خياراتها ومقياس النافذة وسلوك الطابع الزمني بين Linux و Windows و Apple. أجهزة Apple ترسل خيارات TCP بالترتيب: MSS, NOP, WS, NOP, NOP, TS, SACK_PERM, EOL، بينما يرسل Linux: MSS, SACK_PERM, TS, NOP, WS. إذا زعم المتصفح أنه iOS بينما توقيع النواة هو Linux، فإن الاتصال لم يُفتح من هاتفك، بل أُعيد بناؤه بواسطة جهاز آخر، وهو دائماً خادم بروكسي أو عقدة CDN.

💡 تحقق من تطابق عتاد جهازك ورسم Canvas و WebGL عبر فحص بصمة المتصفح.

الحد الأقصى لحجم المقطع (MSS) المعلن في حزمة SYN يتيح لنا حساب وحدة الإرسال للمسار: MTU تساوي MSS زائد 40 بايت في IPv4 وزائد 60 بايت في IPv6. لكل نوع اتصال قيمة مميزة: الخط المنزلي عبر PPPoE هو 1492، وشبكات الهاتف المحمول تقع بين 1400 و 1430، وأنفاق WireGuard تكون افتراضياً 1420، بينما شبكة الإيثرنت النقية — والتي تعني عملياً خادماً في مركز بيانات — هي 1500. لذلك، فإن إبلاغ هاتف عن قيمة 1500 يمثل تناقضاً يستحق الرصد: فلا توجد شبكة هاتف محمول تقدم هذه القيمة. أما على أجهزة الكمبيوتر المكتبية، فقد تعني شبكة LAN محلية أو اتصال ألياف بصرية دون PPPoE، لذا نمنحها وزناً أقل.

💡 إذا كنت تشك في وجود قواعد توجيه شاذة، اختبر وجهات متعددة عبر فحص تقسيم المسارات والتسريب.

لأن سمعة عنوان الـ IP وسلوك البروتوكول مسألتان مستقلتان تماماً. شراء عنوان IP سكني يغير فقط ما تقوله قواعد البيانات عن عنوانك، لكنه لا يغير طريقة بناء الحزم لجهاز الخروج. إذا كان الخادم يعمل بنظام Linux، فسيظل يرسل خيارات TCP لـ Linux، ويعلن عن MTU لمركز البيانات، وينهي مصافحة TLS ببصمته الخاصة. أنظمة الحماية التي تفحص حزمة البروتوكول ترى خادماً لا خطاً منزلياً. هذا هو أكثر الأخطاء شيوعاً، ولهذا يفصل تقريرنا الأدلة المثبتة من البروتوكول عن تلك المستندة إلى السمعة.

💡 يمكنك الاطلاع على تفاصيل ASN وتقييم مخاطر الاحتيال في الصفحة الرئيسية لـ MyIPDNS.

يعني هذا أننا لم نتمكن من العثور على تناقض في طبقات البروتوكول، ونعتمد على ما تقوله قواعد بيانات العناوين حول منفذ خروجك. يحدث هذا عندما يعمل جهازك وخادم البروكسي بنفس عائلة نظام التشغيل. فحاسوب مكتبي يعمل بنظام Linux خلف بروكسي يعمل بنظام Linux يُنتج بصمة Linux متسقة واحدة، ومن ثم لا يجد التحليل عبر الطبقات ما يقارنه. نحن نحدد الحكم بنزاهة بدلاً من إخفاء نقاط الضعف: فالأدلة المصنفة كـ "بروتوكول" تم إثباتها من الحزم، بينما الأدلة المصنفة كـ "سمعة" لم تكن كذلك. ويجب قراءة أي حكم منخفض الثقة مبني فقط على السمعة على أنه مجرد تلميح، وليس كدليل قاطع.

💡 يمكن للمطورين الاستعلام برمجياً عن بيانات ASN المنظمة وبيانات تقييم المخاطر عبر واجهة API المجانية الخاصة بنا.

بعض الإشارات ترجع إلى الإعدادات وبعضها يتعلق بالفيزياء. يمكن إخفاء MTU لمركز البيانات من خلال ضبط MTU لواجهة النفق على خادمك على قيمة بين 1420 و 1450، مما يجعل المسار يبدو كنفق مستخدم عادي. وتختفي إزاحات الطوابع الزمنية المشتركة لـ TCP عندما يشغّل مضيف الخروج نواة تعيد توليد الإزاحة عشوائياً لكل اتصال بدلاً من حساب تجزئتها لكل زوج عناوين. أما عدم التطابق بين نظام تشغيل خادم الخروج والنظام الذي يدعيه متصفحك، فلا يمكن إصلاحه عبر إعدادات العميل على الإطلاق: إذ لا يزول إلا إذا كان مضيف الخروج يشغل نفس عائلة نظام التشغيل، أو إذا تمت إعادة كتابة خيارات SYN عند منفذ الخروج. ولا يمكن لأي إضافة متصفح تغيير أي من هذا، لأن أياً منها لا يتم إنشاؤه بواسطة المتصفح.

💡 بعد تعديل إعدادات شبكتك، عد إلى الصفحة الرئيسية لإعادة إجراء اختبارات الاتصال الكامل وبصمة المكدس.

كلا. فكل ما يتم وصفه هنا يُستنتج من الحزم التي تصل بالفعل إلى مسابيرنا، والتي تحمل عنوان منفذ خروجك ولا شيء غير ذلك. يمكننا في كثير من الأحيان معرفة أن الاتصال قد أُعيد بناؤه في نقطة ما على طول المسار، ويمكننا وصف خصائص الجهاز الذي أعاد بناءه، ولكن عنوان الجهاز الذي فتح الجلسة في الأصل ليس موجوداً في حركة المرور تلك ولا يمكن استرداده منها. وبشكل منفصل، يمكن لفحوصات WebRTC و DNS على هذا الموقع أن تكشف عن عنوان محلي إذا قام متصفحك أو المحلل (resolver) بتسريبه، وتلك آلية مختلفة تماماً ويتم الإبلاغ عنها على حدة.

💡 لتشخيص توجيه المسابير المتعددة وتباين DNS، راجع تشخيص تسريب المسارات الخاص بنا.