LEAK GUIDE

نشت DNS چیست · توضیحات فنی تشخیص نشت

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

بازگشت به تست نشت

Technical Notes

توضیح WebRTC، UDP و نشت DNS

نشت WebRTC چیست

WebRTC قابلیت ارتباط بلادرنگ داخلی مرورگر است که برای ویدئوکنفرانس، تماس صوتی، انتقال فایل P2P و سناریوهای مشابه به کار می‌رود. برای برقراری اتصال همتا به همتا، مرورگر از طریق یک سرور STUN آدرسی را که از سمت اینترنت عمومی برایش دیده می‌شود کشف می‌کند. این کاوش معمولاً از UDP استفاده می‌کند و پروکسی‌های معمولی HTTP / SOCKS لزوماً UDP را در دست نمی‌گیرند.

اگر درخواست STUN پروکسی را دور بزند و مستقیماً از شبکه محلی ارسال شود، اسکریپت صفحه وب ممکن است IP عمومی واقعی شما را به دست آورد. این فرایند معمولاً به مجوز دوربین یا میکروفون نیاز ندارد و پیام تأیید اضافه‌ای هم نمایش نمی‌دهد؛ به همین دلیل اغلب برای بررسی اینکه آیا پروکسی واقعاً ترافیک ارتباط بلادرنگ را پوشش می‌دهد یا نه، استفاده می‌شود.

این ابزار چگونه آن را تشخیص می‌دهد

صفحه تلاش می‌کند با چند سرور STUN کاوش WebRTC انجام دهد، آدرس‌های عمومی برگشتی را جمع‌آوری می‌کند و آن‌ها را با IP خروجی HTTP مقایسه می‌کند. اگر آدرس برگشتی با خروجی فعلی یکسان باشد، به احتمال زیاد مسیر UDP توسط پروکسی مدیریت می‌شود؛ اگر آدرسی از اپراتور محلی برگردد، باید آن را دقیق بررسی کرد.

بررسی اینکه آیا UDP از خروجی پروکسی عبور می‌کند
تشخیص اینکه آیا IPv4 / IPv6 هرکدام جداگانه نشت می‌کنند
مشاهده اینکه آیا اهداف مختلف STUN با قواعد مسیریابی متفاوتی منطبق می‌شوند

نقش STUN و UDP

UDP یک پروتکل انتقال بدون اتصال است که معمولاً برای صدا، ویدئو، بازی و ارتباط بلادرنگ استفاده می‌شود. کار STUN ساده است: شما یک بسته UDP به سرور می‌فرستید و سرور IP مبدئی را که دیده است به شما می‌گوید. WebRTC برای مذاکره اتصال به همین نتیجه متکی است، بنابراین آدرسی که STUN می‌بیند شاهد کلیدی برای قضاوت درباره نشت است.

نتایج را چگونه تفسیر کنیم

نشتی شناسایی نشدIP عمومی برگردانده‌شده توسط WebRTC با خروجی فعلی پروکسی شما یکسان است (برای IPv6، همان /64). اگر اصلاً هیچ IP عمومی برنگردد، فقط یعنی تست پاسخی دریافت نکرده است؛ این دلیلی بر امن بودن نیست.

مشکوک به نشتWebRTC یک IP عمومی متفاوت برگرداند و موقعیت، اپراتور یا ASN آن به شبکه محلی واقعی شما اشاره می‌کند.

تفکیک ترافیک عادیچند سرور STUN خروجی‌های پروکسی متفاوتی برگرداندند، اما این خروجی‌ها با مسیریابی یا قواعدی که پیکربندی کرده‌اید مطابقت دارند.

پس از یافتن نشت چه باید کرد

کلاینت پروکسی خود را به حالت TUN تغییر دهید تا UDP مربوط به WebRTC نیز از خروجی پروکسی عبور کند.
Chrome / Edge: سیاست سازمانی <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> را تنظیم کنید؛ Firefox: گزینه <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> را در <code>about:config</code> فعال کنید. WebRTC را کاملاً حذف نکنید، زیرا مرورگری که WebRTC ندارد خودش قابل شناسایی است.
Brave: سیاست مدیریت IP در WebRTC را روی «Disable non-proxied UDP» تنظیم کنید.
وقتی به کنفرانس یا تماس صوتی نیاز دارید، ابتدا قواعد مسیریابی UDP / STUN را در کلاینت پروکسی خود اصلاح کنید.

چند IP خروجی لزوماً به معنای نشت نیست

اگر تفکیک ترافیک را پیکربندی کرده باشید، سرورهای مختلف STUN ممکن است از گره‌های متفاوتی عبور کنند — برای مثال STUN مربوط به Google از خروجی آمریکا و STUN مربوط به Cloudflare از خروجی هنگ‌کنگ. این لزوماً خطرناک نیست؛ مهم این است که با طراحی قواعد شما مطابقت داشته باشد. چیزی که واقعاً باید مراقبش باشید این است که همه آدرس‌های WebRTC به موقعیت فیزیکی شما یا ارائه‌دهنده اینترنت محلی‌تان اشاره کنند.

نشت DNS هم به همان اندازه مهم است

نشت WebRTC «IP واقعی شما» را افشا می‌کند؛ نشت DNS افشا می‌کند «چه دامنه‌هایی را استعلام کرده‌اید». اگر درخواست‌های DNS از پروکسی عبور نکنند، اپراتور محلی یا ریزالور بالادستی شما همچنان می‌تواند ببیند از چه سایت‌هایی بازدید کرده‌اید.

تشخیص نشت DNS در این صفحه با یک پروب واقعی انجام می‌شود: CleanIP.io در یوتا، آمریکا (ns1) و لس‌آنجلس، آمریکا (ns2) هرکدام یک NS معتبر اجرا می‌کند که ناحیه dp.cleanip.io را سرویس می‌دهند. در هر بار تشخیص، نام 8 زیردامنه مستقل <uuid>.dp.cleanip.io تفکیک می‌شود؛ این استعلام‌ها از ریزالور stub سیستم شما ← ارائه‌دهنده اینترنت / VPN / ریزالور بازگشتی عمومی عبور می‌کنند و در نهایت به NS معتبر ما می‌رسند، که IP ریزالور درخواست‌کننده و (در صورت وجود) EDNS Client Subnet (زیرشبکه کلاینت) را ثبت می‌کند و سپس برای مقایسه به شما برمی‌گرداند.

روی دو سیگنال تمرکز کنید: ① زیرشبکه ECS — اگر ریزالور بازگشتی زیرشبکه کلاینت شما را ارسال کرده باشد (در Google 8.8.8.8 رایج است)، آن زیرشبکه مدرک قطعی هویت کلاینت شماست؛ ② کشور ریزالور — Anycast فرامرزی برای ریزالورهای بازگشتی عمومی (1.1.1.1 / 8.8.8.8) طبیعی است؛ نکته مهم این است که وقتی فکر می‌کنید VPN شما روشن است، آیا موقعیت ریزالور با کشور خروجی HTTP شما یکی است یا نه.

چرا حالت پروکسی و حالت TUN نتایج متفاوتی می‌دهند

پروکسی‌های HTTP / SOCKS معمولاً فقط TCP را مدیریت می‌کنند، بنابراین UDP مورد نیاز STUN ممکن است ارسال نشود و صفحه ممکن است «بدون نشت» نشان دهد. این به این معنا نیست که UDP به‌طور امن پروکسی شده است — فقط یعنی UDP هرگز به سرور STUN نرسیده است. حالت TUN هم TCP و هم UDP را روی کارت شبکه مجازی در دست می‌گیرد، بنابراین مسیر واقعی خروجی UDP را بهتر نشان می‌دهد.

حالتSTUN UDPمعنای نتیجه

پروکسی HTTP / SOCKSممکن است ارسال نشود«بدون نشت» ممکن است فقط به معنای مسدود شدن UDP باشد

TUN / کارت شبکه مجازیواقعاً ارسال می‌شودمناسب‌تر برای بررسی خروجی UDP و قواعد مسیریابی

توصیه می‌کنیم در همان حالت شبکه‌ای که واقعاً استفاده می‌کنید دوباره تست کنید: اگر معمولاً از TUN استفاده می‌کنید، با TUN تست کنید؛ اگر به پروکسی مرورگر متکی هستید، مطمئن شوید که مسدود شدن UDP به اشتباه امن تلقی نشده است. هنگام قضاوت درباره نشت WebRTC، روی ASN و موقعیت IP برگشتی و مطابقت آن با انتظارات شما از تفکیک ترافیک تمرکز کنید.