تست میزان ناشناسی پروکسی: سنجش سطح پنهان‌سازی فیلترشکن و نشت حریم خصوصی

زیرا این دو گزاره از لایه‌های مختلفی می‌آیند و فقط یکی از آنها در مرورگر قابل جعل است. هدر User-Agent یک رشته متنی ساده است که هر مرورگر یا افزونه‌ای می‌تواند آن را تغییر دهد. اما بسته TCP SYN که اتصال را ایجاد می‌کند توسط هسته سیستم‌عامل ساخته می‌شود و ترتیب گزینه‌ها، مقیاس پنجره و رفتار زمان‌سنجی آن بین لینوکس، ویندوز و اپل کاملاً متفاوت است. دستگاه‌های اپل گزینه‌های TCP را به ترتیب MSS, NOP, WS, NOP, NOP, TS, SACK_PERM, EOL ارسال می‌کنند؛ در حالی که لینوکس به ترتیب MSS, SACK_PERM, TS, NOP, WS می‌فرستد. اگر مرورگر ادعای iOS داشته باشد اما امضای کرنل لینوکس باشد، اتصال TCP رسیده به ما توسط گوشی شما باز نشده است؛ بلکه توسط دستگاه دیگری (معمولاً سرور فیلترشکن، پروکسی یا CDN) بازسازی شده است.

💡 جهت بررسی همخوانی سخت‌افزار، Canvas و WebGL دستگاه خود، از تست اثر انگشت مرورگر استفاده کنید.

حداکثر اندازه سگمنت (MSS) اعلام‌شده در بسته SYN به ما امکان می‌دهد MTU مسیر را محاسبه کنیم: MTU برابر است با MSS به علاوه 40 بایت در IPv4 و 60 بایت در IPv6. انواع مختلف اتصالات مقادیر متمایزی دارند: اینترنت خانگی PPPoE برابر با 1492 است، شبکه‌های موبایل معمولاً بین 1400 تا 1430 هستند، تونل‌های WireGuard به طور پیش‌فرض 1420 هستند و اترنت خالص دیتاسنتر برابر با 1500 است. از این رو، گزارش عدد 1500 توسط یک گوشی موبایل یک تناقض فنی آشکار است: هیچ اتصال دیتای موبایلی این عدد را تولید نمی‌کند. البته همین عدد در کامپیوتر رومیزی اهمیت کمتری دارد چون شبکه‌های LAN اداری نیز به 1500 می‌رسند.

💡 اگر به وجود مشکل در قوانین فیلترشکن خود مشکوکید، مقاصد مختلف را با تست تفکیک ترافیک و نشت مسیر بررسی کنید.

زیرا اعتبار آی‌پی و رفتار پروتکل دو مقوله مستقل هستند. خرید آی‌پی مسکونی فقط توصیف دیتابیس‌ها از نشانی شما را تغییر می‌دهد، اما شیوه بسته‌بندی داده‌ها توسط سرور خروجی را عوض نمی‌کند. اگر سرور خروجی لینوکسی باشد، همچنان گزینه‌های TCP لینوکس را می‌فرستد، MTU دیتاسنتر را اعلام می‌کند و دست‌دادن TLS را با اثر انگشت خود خاتمه می‌دهد. سیستمی که فقط لیست‌های IP را نگاه می‌کند یک آدرس مسکونی تمیز می‌بیند؛ اما سیستمی که پشته پروتکل را بررسی می‌کند متوجه یک سرور می‌شود. به همین دلیل ما شواهد اثبات‌شده پروتکلی را از اعتبار ساده آی‌پی تفکیک کرده‌ایم.

💡 جزئیات کامل ASN و نمره ریسک تقلب را در صفحه اصلی MyIPDNS مشاهده کنید.

یعنی ما هیچ تناقضی در لایه‌های پروتکل پیدا نکردیم و صرفاً به ارزیابی دیتابیس‌های نشانی اتکا کرده‌ایم. این اتفاق زمانی رخ می‌دهد که دستگاه شما و سرور پروکسی از یک خانواده سیستم‌عامل باشند (مثلاً یک دسکتاپ لینوکس پشت پروکسی لینوکس). ما این محدودیت را صادقانه بیان می‌کنیم: شواهد دارای برچسب پروتکل از روی بسته‌ها اثبات شده‌اند، اما شواهد دارای برچسب اعتبار صرفاً بر اساس پیشینه آی‌پی هستند و باید به عنوان یک سرنخ در نظر گرفته شوند نه مدرک قطعی.

💡 توسعه‌دهندگان می‌توانند داده‌های ASN و نمره ریسک را به صورت ساختاریافته از طریق API رایگان استعلام IP دریافت کنند.

برخی نشانه‌ها به پیکربندی مربوط هستند و برخی به ماهیت فیزیکی شبکه. MTU دیتاسنتر را می‌توان با تنظیم MTU اینترفیس تونل در سرور روی مقداری بین 1420 تا 1450 اصلاح کرد تا شبیه یک تونل عادی کاربر به نظر برسد. افست برچسب زمانی مشترک TCP با ارتقای هسته لینوکس سرور به نسخه‌ای که افست‌ها را تصادفی‌سازی می‌کند حل می‌شود. اما تضاد بین سیستم‌عامل سرور خروجی و مرورگر با هیچ تنظیماتی در کلاینت برطرف نمی‌شود؛ مگر اینکه سرور خروجی از همان سیستم‌عامل شما استفاده کند یا گزینه‌های SYN در خروجی بازنویسی شوند. افزونه‌های مرورگر قادر به تغییر این موارد نیستند زیرا این لایه‌ها خارج از کنترل مرورگرند.

💡 پس از تغییر تنظیمات شبکه، به صفحه اصلی بازگردید تا وضعیت شبکه خود را مجدداً بسنجید.

خیر. تمام نتایج این بخش از روی بسته‌هایی که واقعاً به پروب‌های ما می‌رسند و فقط نشانی خروجی را با خود دارند استنتاج می‌شود. ما می‌توانیم تشخیص دهیم اتصال در میانه راه بازسازی شده و مشخصات دستگاه بازسازی‌کننده را استخراج کنیم، اما نشانی دستگاه اصلی که نشست را شروع کرده درون این بسته‌ها نیست. البته تست‌های مجزای WebRTC و DNS در این سایت در صورت نشت توسط مرورگر، آی‌پی واقعی را نشان می‌دهند که مکانیزمی کاملاً جداگانه است.

💡 برای ارزیابی همگرایی مسیرهای چندپروبی و DNS، به راهنمای تشخیص نشت مسیر مراجعه فرمایید.