تست پیشرفته نشت IP و DNS: ارزیابی کامل امنیت شبکه

بسیاری از کاربران تصور می‌کنند خرید پروکسی مسکونی آنها را کاملاً مانند یک کاربر خانگی نشان می‌دهد. اما سیستم‌های ضد تقلب مدرن فراتر از برچسب‌های دیتابیس‌های GeoIP عمل می‌کنند. حتی اگر آی‌پی در دیتابیس‌ها به عنوان اینترنت خانگی ثبت شده باشد، گیت‌وی پروکسی روی یک سرور لینوکسی ابری اجرا می‌شود و تضادهای بین‌لایه‌ای پدید می‌آورد: اول، امضای پشته انتقال؛ سرور خروجی گزینه‌های TCP لینوکس (MSS, SACK_PERM, TS, NOP, WS) را ارسال می‌کند نه گزینه‌های ویندوز یا مک. دوم، اختلاف MTU؛ اینترنت خانگی PPPoE معمولاً دارای MTU برابر با 1492 است (یا 1400–1430 در شبکه همراه)، در حالی که اترنت دیتاسنتر 1500 (MSS=1460) است. وقتی سیستم امنیتی یک آی‌پی مسکونی را همراه با MTU دیتاسنتر و پشته لینوکس ببیند، اتصال را به عنوان پروکسی شناسایی می‌کند.

💡 با اجرای تست میزان ناشناسی پروکسی محل پایان اتصال TCP خود را مشاهده کنید.

هیچ پیوند فیزیکی ثابتی بین یک نشانی IP و موقعیت جغرافیایی فیزیکی وجود ندارد. نتایج موقعیت مکانی به پایگاه داده تجاری GeoIP مورد استفاده هر سایت و چرخه به‌روزرسانی آن بستگی دارد: نخست، تفاوت در منابع پایگاه داده و مدل‌های دورسنجی—ارائه‌دهندگان (مانند MaxMind، IP2Location، DB-IP) به اعلامیه‌های BGP، ورودی‌های رجیستری whois و پروب‌های تاخیر شبکه وزن‌های متفاوتی می‌دهند و فواصل به‌روزرسانی آن‌ها از چند روز تا چند ماه متغیر است. دوم، مسیریابی Anycast و تحویل لبه CDN: ارائه‌دهندگانی مانند Cloudflare یک بلوک IP یکسان را از صدها دیتاسنتر در سراسر جهان اعلام می‌کنند و بسته شما را به نزدیک‌ترین مکان هم‌مکانی لبه (edge colocation) هدایت می‌نمایند. سوم، تخصیص مجدد فرامرزی IP: هنگامی که یک ارائه‌دهنده میزبانی، یک بلوک IP ثبت‌شده در یک کشور را به سرورهایی در کشور دیگر اختصاص می‌دهد، پایگاه‌های داده قدیمی مبدا تاریخی را گزارش می‌کنند. ابزار ما بررسی متقابل چند پایگاه داده را با چندموقعیت‌یابی بر پایه تاخیر فیزیکی RTT و سرعت نور ترکیب می‌کند تا مناطق فیزیکی واقعی را اعتبارسنجی نماید.

نمره تقلب IP (یا نمره ریسک) یک شاخص عددی (معمولاً 0 تا 100) است که توسط موتورهای ریسک برای سنجش احتمال این‌که یک اتصال از فعالیت‌های سوءاستفاده‌جویانه، ربات یا فعالیت‌های پنهان‌سازی‌شده منشا گرفته باشد، به کار می‌رود. عوامل اصلی ارزیابی عبارتند از: نخست، سابقه و لیست‌های سوءاستفاده: آیا این IP در بازه‌های زمانی 24 تا 72 ساعت گذشته در حملات پر کردن اطلاعات احراز هویت (credential stuffing)، اسکرپینگ (scraping)، اسپم (spamming) یا اسکن (scanning) دست داشته است یا خیر. دوم، نوع ASN و زیرساخت: محدوده‌های دیتاسنتر (میزبانی) و پروکسی/VPN عمومی ریسک پایه بالاتری نسبت به اینترنت پهن‌باند خانگی یا اپراتورهای تلفن همراه دارند. سوم، سازگاری چندنقطه‌ای و پروتکلی: آیا یک نشست دارای خروجی‌های پشته دوگانه تفکیک‌شده (دوگانگی و انحراف IPv4 و IPv6)، انحراف موقعیت مکانی تحلیل‌گر DNS، یا افشای IP محلی از طریق WebRTC هست یا خیر.

💡 با استفاده از تست تفکیک تونل (Split Tunneling) ما نشت‌های مسیریابی را که ممکن است نمره ریسک شما را افزایش دهند، شناسایی کنید.

حتی با روشن بودن فیلترشکن، هویت واقعی شما ممکن است از کانال‌های جانبی لو برود: اول، نشت DNS؛ اگر کلاینت فیلترشکن نتواند درخواست‌های DNS سیستم‌عامل را مدیریت کند، درخواست‌ها مستقیماً و به صورت شفاف به سرورهای DNS اپراتور محلی شما (ISP) ارسال می‌شوند و سایت‌های مشاهده‌شده را فاش می‌کنند. دوم، نشت WebRTC؛ پروتکل وب‌آرتی‌سی برای ارتباط صوتی و تصویری در مرورگر استفاده می‌شود و هنگام برقراری ارتباط، لایه‌های پروکسی را دور زده و مستقیماً بسته‌های UDP به سرورهای STUN ارسال می‌کند که باعث افشای آی‌پی واقعی شما می‌شود. صفحه اصلی ما نشت DNS و وضعیت WebRTC را به طور بلادرنگ بررسی می‌کند.

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

پنل پشته شبکه در صفحه اصلی سه پروب مرتبط را به صورت موازی اجرا می‌کند: یکی به دامنه‌ای با تنها رکوردهای A (iptestv4.myipdns.com)، یکی به دامنه‌ای با تنها رکوردهای AAAA (iptestv6.myipdns.com)، و سومی به دامنه‌ای دوپشته با هر دو خانواده رکورد متصل می‌شود. دو پروب اول اجباری هستند—هر نام میزبان فقط به یک خانواده نشانی تحلیل می‌شود و هیچ انتخابی برای سیستم شما باقی نمی‌گذارد، بنابراین IP خروجی واقعی شما را روی IPv4 و IPv6 به طور مستقل ثبت می‌کند. پروب سوم اجباری نیست؛ در عوض، بررسی می‌کند که سیستم شما خود به خود کدام خانواده نشانی را انتخاب کرده است، که در ستون «پروتکل دارای اولویت» نشان داده می‌شود: این نتیجه توسط خط‌مشی انتخاب نشانی سیستم‌عامل و مرورگر شما تعیین می‌شود (Happy Eyeballs، RFC 8305: در صورت در دسترس بودن پشته دوگانه، ابتدا IPv6 امتحان می‌شود و تنها در صورت شکست، به IPv4 بازمی‌گردد)، نه این‌که توسط ما مشخص شده باشد. قرار دادن هر سه مورد در کنار هم بسیار حیاتی است زیرا بسیاری از کلاینت‌های پروکسی و VPN فقط IPv4 را تونل می‌کنند: اگر خروجی IPv4 شما روی ASN پروکسی باشد در حالی که خروجی IPv6 شما روی ISP اینترنت خانگی‌تان باقی بماند و پروتکل دارای اولویت نیز IPv6 را نمایش دهد، آن‌گاه هنگام بازدید از وب‌سایت‌های دارای پشته دوگانه بخش عمده ترافیک شما هرگز از تونل عبور نمی‌کند—این متداول‌ترین شکل از «VPN فعال است اما هویت واقعی فاش شده» است و هیچ‌گونه خطایی هم صادر نمی‌کند.

⚠ ما فقط می‌توانیم به شما بگوییم که آیا خروجی‌های دو خانواده نشانی شما در شبکه‌های متفاوتی خاتمه می‌یابند یا خیر؛ ما نمی‌توانیم قضاوت کنیم که نرم‌افزار پروکسی شما چگونه باید پیکربندی شود. بالعکس، نمایش IPv6 به عنوان غیرقابل دسترس معادل امنیت نیست؛ ممکن است به سادگی به این معنی باشد که شبکه شما فاقد IPv6 است، یا این‌که پروکسی شما IPv6 را به طور کامل غیرفعال کرده است—که مورد دوم اغلب رفتار مورد انتظار است.

ما تنظیمات سیستم محلی شما را نمی‌خوانیم—مرورگرها اصلاً قادر به خواندن آن‌ها نیستند، و هر صفحه وبی که ادعا می‌کند پیکربندی DNS محلی شما را می‌خواند صرفاً حدس می‌زند. رویکرد واقعی آزمون معکوس است: سایت ما یک سرور معتبر DNS (Authoritative) را اداره می‌کند و برای هر آزمایش یک زیردامنه تصادفی یکتا (مانند k3f9x2ab.leakv4.myipdns.com) ایجاد می‌نماید تا مرورگر شما آن را تحلیل کند. این نام میزبان تنها یک بار در تاریخ ظاهر می‌شود و هرگز در هیچ حافظه کش وجود نخواهد داشت، بنابراین زنجیره تحلیل بازگشتی شما باید در تمام مسیر تا مبدا از سرور معتبر ما پرس‌وجو کند؛ ما ثبت می‌کنیم که چه کسی واقعاً پرس‌وجو را انجام داده است، و سپس آن نشانی را به مرورگر شما بازمی‌گردانیم. در نتیجه، ستون «خروجی DNS» نشانی شبکه خروجی واقعی تحلیل‌گر بازگشتی شما را نمایش می‌دهد، نه IP بالادستی که در تنظیمات سیستم خود وارد کرده‌اید: اگر 8.8.8.8 را تنظیم کنید، دستگاهی که از ما پرس‌وجو می‌کند یک گره خروجی خاص در آن کلاستر خواهد بود که چه بسا در کشور دیگری مستقر باشد؛ تحلیل‌گرهای عمومی بزرگ به anycast و کلاسترینگ متکی هستند، بنابراین مشاهده چندین نشانی خروجی متفاوت در یک آزمایش کاملاً طبیعی است. معیار واقعی این نیست که آیا نشانی‌ها مطابقت دارند یا خیر، بلکه این است: اگر این خروجی درون شبکه ISP پهن‌باند خودتان قرار گیرد در حالی که خروجی IP شما روی پروکسی خاتمه می‌یابد—این امر نشان می‌دهد که پرس‌وجوهای DNS نتوانسته‌اند از تونل عبور کنند.

⚠ این روش فقط می‌تواند مشاهده کند چه کسی از سرور معتبر خود ما پرس‌وجو کرده است؛ ما هیچ دامنه دیگری را که تحلیل می‌کنید نمی‌توانیم ببینیم و نمی‌بینیم. همچنین یک نقطه کور شناخته‌شده وجود دارد: اگر پروکسی شما پرس‌وجوهای DNS را نیز رهگیری کند، آنچه ما مشاهده می‌کنیم تحلیل‌گر ارائه‌دهنده پروکسی است—که عدم نشت به ISP محلی شما را تایید می‌کند، اما گزارش پرس‌وجوهای DNS شما همچنان برای ارائه‌دهنده پروکسی قابل مشاهده باقی می‌ماند؛ این موضوعی جداگانه فراتر از مواردی است که این ابزار شناسایی می‌کند.

از طریق WebRTC، پروب‌های منفرد به چندین سرور STUN ارسال می‌شوند تا کاندیداهای srflx بازگردانده‌شده را جمع‌آوری کنند—یعنی IP و پورت عمومی که در عمل توسط سرور راه دور پس از ترجمه NAT مشاهده می‌شود. تنها یک معیار تعیین‌کننده وجود دارد: کاندیداها بر اساس IP عمومی ترجمه‌شده گروه‌بندی می‌شوند؛ اگر دو یا چند پورت متمایز ذیل یک IP یکسان ظاهر شوند، به عنوان Symmetric NAT (تخصیص یک پورت نگاشته‌شده جدید برای هر مقصد متمایز) طبقه‌بندی می‌شود؛ در غیر این صورت، به عنوان Cone NAT (نگاشت مداوم همان پورت داخلی به همان پورت خارجی) طبقه‌بندی می‌گردد. گروه‌بندی کاندیداها قبل از مقایسه پورت‌ها عمداً معرفی شد: در محیط‌های پروکسی با تونل تفکیک‌شده (split-tunnel)، سرورهای مختلف STUN ممکن است از خروجی‌های متفاوتی مسیریابی شوند که طبیعتاً باعث واگرایی پورت‌ها می‌شود؛ با این حال، این واگرایی از تفاوت‌های مسیر ناشی می‌شود نه رفتار NAT، و عدم گروه‌بندی باعث می‌شد همه چنین ساختارهایی به اشتباه به عنوان Symmetric تشخیص داده شوند. نمایش وضعیت «نامشخص» دو علت دارد: نخست، عدم دریافت هیچ کاندیدای srflx در مهلت زمانی 4 ثانیه‌ای (غیرفعال بودن WebRTC در مرورگر، مسدود شدن توسط افزونه‌ها، یا فیلتر شدن UDP خروجی)؛ دوم، دریافت تنها یک کاندیدای منفرد که IP عمومی آن با IP ورودی استفاده‌شده برای دسترسی به این سایت مطابقت ندارد، که تشخیص تفکیک مسیریابی ترافیک از حذف موارد تکراری کاندیدا توسط مرورگر را غیرممکن می‌سازد، بنابراین ما عمداً وضعیت نامشخص را نمایش می‌دهیم.

⚠ شفاف‌سازی صادقانه: ما فقط بین Cone NAT و Symmetric NAT تمایز قائل می‌شویم و زیرطبقه‌بندی به Full Cone، Restricted Cone یا Port-Restricted Cone انجام نمی‌دهیم. مدل چهارسطحی RFC 3489 مستلزم کنترل فعال ترکیب پورت‌های مبدا و اهداف مقصد در طول پروب‌های مکرر است و WebRTC در مرورگرها چنین کنترل سطح پایینی را فراهم نمی‌کند؛ هنگامی که ابزارهای مبتنی بر وب یکی از آن چهار دسته را گزارش می‌کنند، معمولاً صرفاً در حال برچسب‌گذاری مجدد همین دو نتیجه هستند.

بررسی در صفحه اصلی از چند گروه درخواست تشکیل شده است: اتصال به چند زیردامنه از این سایت برای جمع‌آوری ویژگی‌های پشته پروتکل در IPv4 و IPv6 و نسخه‌های مختلف HTTP؛ استعلام از چند سرویس شخص ثالث استعلام IP و همچنین WebRTC برای مشاهده اینکه آیا مقصدهای مختلف خروجی یکسانی را می‌بینند یا خیر؛ تحلیل زیردامنه‌های تصادفی برای بررسی اینکه چه کسی درخواست‌های DNS شما را پاسخ می‌دهد؛ ارسال کاوشگر به گره‌های ما در مناطق دیگر برای اعتبارسنجی متقابل از چند موقعیت مکانی؛ و اندازه‌گیری تاخیر به چند وب‌سایت پربازدید.

⚠ نقطه ضعف این است که هنگام بارگذاری به دامنه‌های متعددی متصل می‌شوید که مسدودکننده‌های تبلیغات یا افزونه‌های سخت‌گیرانه حریم خصوصی گاهی بخشی از آن‌ها را مسدود می‌کنند. مورد آسیب‌دیده با یک نقطه خاکستری نمایش داده می‌شود و در وضعیت نامشخص باقی می‌ماند و ما آن را با نتایج دیگر پر نخواهیم کرد.