نشت WebRTC و DNS: چیست و چگونه جلوی آن را بگیریم

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

در این نوشته توضیح می‌دهیم نشت IP چیست، WebRTC با چه سازوکاری آدرس واقعی را فاش می‌کند، نشت DNS از کجا می‌آید و چگونه هر دو را بیازمایید. سپس به تنظیمات کروم و فایرفاکس برای بستن نشت، اهمیت resolve از راه دور DNS در SOCKS5 و نشانه‌های دیگری جز IP که موقعیت شما را لو می‌دهند می‌پردازیم. در پایان یک فهرست بررسی یک‌صفحه‌ای آمده است.

نشت IP چیست؟#

نشت IP یعنی در حالی که از پروکسی یا VPN استفاده می‌کنید، آدرس IP واقعی شما از طریق بخشی از ترافیکتان دیده شود. نشت به این معنا نیست که پروکسی کار نمی‌کند. درخواست‌های HTTP صفحه از پروکسی می‌گذرند و سایت مقصد در این درخواست‌ها آدرس پروکسی را می‌بیند. مشکل این است که مرورگر افزون بر HTTP می‌تواند اتصال‌های شبکه دیگری هم باز کند.

تنظیم پروکسی مرورگر معمولاً فقط درخواست‌های HTTP و HTTPS را پوشش می‌دهد. اتصال‌های دیگر مرورگر این‌ها هستند:

• WebRTC: اتصال‌های مستقیم از راه UDP برای تماس تصویری، اشتراک صفحه و انتقال داده همتا به همتا.
• پرس‌وجوهای DNS: پرس‌وجوهایی که سیستم‌عامل یا مرورگر برای تبدیل نام دامنه به آدرس IP به سرور DNS می‌فرستند.
• افزونه‌های مرورگر و اتصال‌های درون‌برنامه‌ای: مؤلفه‌هایی که تنظیمات شبکه خودشان را دارند.

اگر سایتی آدرس واقعی شما را از یکی از این کانال‌ها ببیند، می‌تواند آن را با آدرسی که پروکسی نشان می‌دهد مقایسه کند. دو آدرس از دو کشور متفاوت آشکارا نشان می‌دهد بازدیدکننده از پروکسی استفاده می‌کند. سازوکار پایه پروکسی را در سرور پروکسی چیست و چگونه کار می‌کند؟ توضیح داده‌ایم.

WebRTC چگونه IP واقعی شما را فاش می‌کند؟#

WebRTC طوری طراحی شده که دو مرورگر بدون عبور از سرور مستقیم با هم حرف بزنند. برای این کار هر مرورگر باید آدرس‌هایی را که از آن‌ها قابل دسترسی است بداند و به طرف مقابل بگوید. این آدرس‌ها نامزدهای ICE نام دارند و فرایند یافتن آن‌ها در ⁦RFC 8445⁩ تعریف شده است.

وقتی صفحه‌ای اتصال WebRTC را آغاز می‌کند، این گام‌ها رخ می‌دهد:

1. صفحه یک RTCPeerConnection می‌سازد. لازم نیست از کاربر اجازه بگیرد؛ دوربین یا میکروفون روشن نمی‌شود. درخواست یک کانال داده کافی است.
2. مرورگر نامزدهای محلی را گرد می‌آورد. این‌ها آدرس‌های رابط‌های شبکه رایانه‌اند (نامزدهای host). مرورگرهای امروزی آدرس محلی را به‌جای نمایش مستقیم، پشت نام تصادفی xxxx.local پنهان می‌کنند.
3. مرورگر یک بسته UDP به سرور STUN می‌فرستد. سرور STUN آدرس IP عمومی و پورتی را که بسته از آن آمده برمی‌گرداند. این آدرس به‌عنوان نامزد srflx (server reflexive) ثبت می‌شود.
4. بسته UDP از پروکسی نمی‌گذرد. پروکسی HTTP فقط ترافیک HTTP را جابه‌جا می‌کند؛ مرورگر بسته STUN را مستقیم از رابط شبکه می‌فرستد. سرور STUN بسته را از IP عمومی واقعی شما می‌بیند.
5. نامزدها به صفحه گزارش می‌شوند. جاوااسکریپت فهرست نامزدها را با رویداد onicecandidate می‌خواند و می‌تواند IP عمومی نامزد srflx را به سرور خودش بفرستد.

نتیجه: صفحه از راه درخواست‌های HTTP آدرس پروکسی و از راه WebRTC آدرس واقعی شما را می‌بیند.

اینکه مرورگرها در WebRTC کدام آدرس‌ها را می‌توانند نشان دهند، در ⁦RFC 8828⁩ در چهار حالت تعریف شده است: استفاده از همه رابط‌ها، فقط مسیر پیش‌فرض همراه آدرس محلی مرتبط، فقط آدرس عمومی مسیر پیش‌فرض، و اجبار UDP به عبور از پروکسی. تنظیمات کروم و فایرفاکس با همین حالت‌ها مطابقت دارند.

نشت DNS چیست؟#

پیش از اتصال به یک سایت، نام دامنه آن باید به آدرس IP تبدیل شود. نشت DNS یعنی این پرس‌وجو به‌جای پروکسی از طریق سرور DNS ارائه‌دهنده اینترنت یا شبکه محلی شما انجام شود.

نشت DNS دو پیامد دارد:

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

نشت DNS بیشتر در این حالت‌ها رخ می‌دهد:

• در پروکسی SOCKS5، کلاینت نام دامنه را خودش resolve می‌کند و فقط آدرس IP را به پروکسی می‌فرستد.
• پروکسی فقط در مرورگر تنظیم شده و برنامه‌های دیگر از DNS سیستم استفاده می‌کنند.
• نرم‌افزار VPN یا پروکسی تنظیمات DNS سیستم‌عامل را تغییر نمی‌دهد.

در پروکسی‌های HTTP و HTTPS، مرورگر نام دامنه را درون درخواست CONNECT example.com:443 به پروکسی می‌فرستد و resolve را پروکسی انجام می‌دهد. همین پروکسی‌های HTTP را برای ترافیک وب مرورگر از نظر نشت DNS کم‌خطرتر می‌کند. سازوکار SOCKS و resolve نام را در پروکسی SOCKS5: چطور کار می‌کند و چه فرقی دارد توضیح داده‌ایم.

چگونه نشت WebRTC و DNS را بیازماییم؟#

صفحه‌های آزمون آماده وجود دارد، اما یک بار انجام دادن آزمون به دست خودتان به شما می‌آموزد به دنبال چه باشید.

آزمون WebRTC#

با پروکسی روشن، هر صفحه‌ای را در مرورگر باز کنید، کنسول ابزارهای توسعه‌دهنده (F12) را باز کنید و این کد را اجرا کنید:

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });
pc.createDataChannel("test");
pc.onicecandidate = (e) => {
  if (e.candidate) console.log(e.candidate.candidate);
};
await pc.setLocalDescription(await pc.createOffer());

چند خط نامزد در کنسول می‌بینید. خطی را که شامل typ srflx است پیدا کنید. اگر آدرس IP آن خط:

• با IP خروجی پروکسی یکی باشد یا اصلاً خط srflx وجود نداشته باشد، نشت WebRTC ندارید.
• IP واقعی شما باشد، نشت WebRTC دارید.

اگر IP واقعی خود را نمی‌دانید، صفحه بررسی IP را با پروکسی خاموش باز کنید.

آزمون DNS#

نشت DNS را نمی‌توان فقط از مرورگر سنجید، چون تنها صاحب دامنه می‌تواند ببیند پرس‌وجو از کدام سرور DNS آمده است. به همین دلیل صفحه‌های آزمون نشت DNS از شما می‌خواهند زیردامنه‌های تصادفی را resolve کنید و نشان می‌دهند کدام سرورهای DNS این پرس‌وجوها را انجام داده‌اند. اگر نتیجه سرورهای DNS ارائه‌دهنده اینترنت خود شما را نشان دهد، پرس‌وجوها از پروکسی نمی‌گذرند.

در خط فرمان، خروجی مفصل cURL نشان می‌دهد پروکسی SOCKS5 با DNS چگونه رفتار می‌کند:

# resolve محلی: نام دامنه روی رایانه شما به IP تبدیل می‌شود
curl -v -x "socks5://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

# resolve از راه دور: نام دامنه به پروکسی فرستاده می‌شود و پروکسی آن را resolve می‌کند
curl -v -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

در خروجی فرمان نخست، cURL گزارش می‌دهد که پیش از اتصال دامنه را resolve کرده و آدرس IP را به پروکسی فرستاده است. در فرمان دوم خود نام دامنه به پروکسی فرستاده می‌شود. همه گزینه‌های پروکسی cURL در استفاده از پروکسی با cURL آمده است.

چگونه جلوی نشت WebRTC را در کروم بگیریم؟#

منوی تنظیمات کروم گزینه‌ای برای خاموش کردن WebRTC ندارد. این رفتار با سیاست سازمانی یا افزونه تغییر می‌کند. روش سیاست به افزونه نیاز ندارد و بر مستندات رسمی گوگل تکیه دارد.

سیاست WebRtcIPHandling در Chrome Enterprise این مقدارها را می‌پذیرد:

مقداری که هنگام استفاده از پروکسی نشت را می‌بندد disable_non_proxied_udp است. در ویندوز می‌توانید این سیاست را از PowerShell که با دسترسی مدیر باز شده در رجیستری بنویسید:

New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "WebRtcIPHandling" -Value "disable_non_proxied_udp"

کروم را کامل ببندید، دوباره باز کنید و در نوار آدرس chrome://policy را بزنید تا بارگذاری سیاست را بررسی کنید. سپس آزمون WebRTC بالا را تکرار کنید.

این تنظیم هزینه‌ای دارد: ابزارهای تماس تصویری و اشتراک صفحه مبتنی بر مرورگر نمی‌توانند از UDP استفاده کنند، پس ممکن است کند شوند یا اصلاً کار نکنند. اگر روی یک رایانه هم کار با پروکسی و هم تماس تصویری دارید، استفاده از پروفایل یا مرورگر جداگانه برای هر کدام کاربردی‌تر است. اینکه کروم تنظیم پروکسی را از کجا می‌خواند در تنظیم پروکسی در ویندوز و کروم آمده است.

چگونه جلوی نشت WebRTC را در فایرفاکس بگیریم؟#

فایرفاکس این تنظیمات را در صفحه about:config در اختیار می‌گذارد. در نوار آدرس about:config را بزنید، هشدار را بپذیرید و تنظیمات زیر را جست‌وجو کنید.

تنظیم نخست می‌کوشد در هنگام استفاده از پروکسی نشت را ببندد بی‌آنکه ابزارهای تماس را کاملاً از کار بیندازد. قرار دادن media.peerconnection.enabled روی false قطعی‌ترین راه است، اما همه قابلیت‌های تماس تصویری و اشتراک صفحه مرورگر را غیرفعال می‌کند.

برای DNS در فایرفاکس، در صفحه تنظیمات پروکسی گزینه Proxy DNS when using SOCKS v5 را هم علامت بزنید. معادل آن در about:config تنظیم network.proxy.socks_remote_dns است. تنظیم کامل پروکسی در فایرفاکس در تنظیمات پروکسی فایرفاکس آمده است؛ برای مدیریت پروکسی به تفکیک پروفایل، راهنمای SwitchyOmega را ببینید.

چرا DNS از راه دور در SOCKS5 مهم است؟#

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

در کتابخانه‌ها و ابزارها این رفتار نام‌های گوناگونی دارد:

• cURL: socks5:// محلی و socks5h:// از راه دور resolve می‌کند.
• Python Requests و HTTPX: طرح socks5h:// در آدرس پروکسی.
• فایرفاکس: گزینه Proxy DNS when using SOCKS v5.
• کروم: در SOCKS5 نام دامنه را به پروکسی می‌فرستد.
• ابزارهای مسیریابی مانند Proxifier: گزینه‌ای با مضمون resolve کردن نام میزبان از طریق پروکسی.

سود دوم resolve از راه دور، سازگاری موقعیت است: وقتی پروکسی DNS را resolve کند، CDNها سروری نزدیک به موقعیت پروکسی برمی‌گردانند. جزئیات فنی SOCKS5 را در پروکسی SOCKS5: چطور کار می‌کند و چه فرقی دارد ببینید. ساختارهایی که ترافیک برنامه‌ها را هم پوشش می‌دهند از پلن‌های پروکسی SOCKS5 استفاده می‌کنند.

نشانه‌هایی جز نشت که موقعیت شما را لو می‌دهند#

پس از بستن نشت IP و DNS، صفحه هنوز می‌تواند از آنچه درباره خود مرورگر می‌داند سرنخ‌هایی از موقعیت شما گرد آورد. این‌ها نشت شبکه نیستند، اما وقتی با موقعیت پروکسی ناسازگار باشند همان اثر را دارند.

• منطقه زمانی. جاوااسکریپت منطقه زمانی سیستم را با Intl.DateTimeFormat().resolvedOptions().timeZone می‌خواند. IP خروجی در آلمان همراه منطقه زمانی Europe/Istanbul تناقض است.
• ترجیح‌های زبانی. navigator.languages و هدر Accept-Language ترتیب زبان‌های مرورگر را نشان می‌دهند.
• اجازه موقعیت. اگر در مرورگر به سایتی اجازه موقعیت داده باشید، API موقعیت‌یابی می‌تواند بر اساس شبکه‌های وای‌فای اطراف موقعیت واقعی شما را برگرداند.
• کوکی‌ها و نشست‌ها. کوکی نشست بازدیدی بدون پروکسی در بازدید با پروکسی هم فرستاده می‌شود و دو بازدید را به هم پیوند می‌دهد.
• اثر انگشت مرورگر. وضوح صفحه، فونت‌ها و اطلاعات کارت گرافیک مرورگر را مستقل از IP شناسایی می‌کنند. جزئیات در اثر انگشت مرورگر آمده است.

اگر باید با بیش از یک هویت کار کنید، ساختارهایی وجود دارد که پروکسی، منطقه زمانی و زبان هر پروفایل را با هم سازگار نگه می‌دارند؛ آن‌ها را در مرورگر آنتی‌دیتکت چیست؟ توضیح داده‌ایم.

کاربردها#

• تیمی که تبلیغات و محتوا را در کشورهای مختلف بررسی می‌کند: نشت WebRTC ممکن است سایت را به دسته‌بندی شما در موقعیت نادرست بکشاند. همراه با پروکسی مسکونی که از خطوط کاربران واقعی خارج می‌شود، تنظیمات مرورگر هم باید اصلاح شود.
• توسعه‌دهنده‌ای که ترافیک موبایلی را می‌آزماید: IP اپراتور موبایل که در WebRTC کنار آدرس واقعی شبکه دسکتاپ دیده شود ناسازگاری می‌سازد. همین بررسی هنگام استفاده از پروکسی موبایل هم لازم است.
• کاربری که برنامه دسکتاپ را از پروکسی عبور می‌دهد: ممکن است پرس‌وجوهای DNS برنامه از DNS سیستم بگذرند؛ resolve از راه دور باید در ابزار مسیریابی روشن شود.
• تیمی که خودکارسازی مرورگر اجرا می‌کند: مرورگرهای خودکارسازی هم از WebRTC پشتیبانی می‌کنند. هنگام اجرای کروم باید همان سیاست یا تنظیم راه‌اندازی معادل به کار رود.

اشتباهات رایج#

• کافی دانستن نتیجه صفحه بررسی IP. این صفحه‌ها فقط آدرس درخواست HTTP را نشان می‌دهند؛ WebRTC و DNS باید جداگانه آزموده شوند.
• تغییر تنظیم بدون راه‌اندازی دوباره مرورگر. سیاست‌های کروم تا وقتی مرورگر کامل بسته و دوباره باز نشود بارگذاری نمی‌شوند.
• استفاده هم‌زمان از VPN و پروکسی و تفسیر نادرست آدرس نشت‌کرده. با VPN روشن، در آزمون WebRTC آدرس VPN دیده می‌شود؛ این آدرس واقعی شما نیست، اما با آدرس پروکسی هم یکی نیست.
• رها کردن طرح socks5:// به‌عنوان پیش‌فرض. بیشتر نمونه‌های کتابخانه‌ها از طرحی استفاده می‌کنند که محلی resolve می‌کند.
• خاموش کردن کامل WebRTC و تعجب از کار نکردن ابزارهای تماس. proxy_only_if_behind_proxy یا پروفایل جداگانه با عوارض کمتر همان نتیجه را می‌دهد.
• فراموش کردن منطقه زمانی و زبان. حتی با بسته شدن نشت‌های شبکه، این نشانه‌ها ناسازگاری موقعیت را آشکار می‌کنند.

فهرست بررسی#

پرسش‌های متداول#

آیا نشت WebRTC فقط کاربران پروکسی را متأثر می‌کند؟#

کاربران VPN را هم می‌تواند متأثر کند، اما چون بیشتر VPNها در سطح سیستم‌عامل کار می‌کنند و ترافیک UDP را هم از تونل می‌گذرانند، نشت کمتر رخ می‌دهد. پروکسی فقط ترافیک HTTP مرورگر را پوشش می‌دهد، پس خطر بیشتر است.

آیا خاموش کردن WebRTC سایت‌ها را خراب می‌کند؟#

تماس تصویری، گفت‌وگوی صوتی، اشتراک صفحه و برخی سرویس‌های انتقال فایل مبتنی بر مرورگر از کار می‌افتند یا کند می‌شوند. بخش بسیار بزرگی از سایت‌های معمولی متأثر نمی‌شوند.

آیا آدرس IP محلی من (192.168...) هنوز نشت می‌کند؟#

نسخه‌های فعلی کروم و فایرفاکس به‌طور پیش‌فرض آدرس‌های محلی را پشت نام‌های تصادفی با پسوند .local پنهان می‌کنند. خطر واقعی IP عمومی است که از راه STUN به دست می‌آید.

آیا با پروکسی HTTP هم نشت DNS رخ می‌دهد؟#

معمولاً نه برای ترافیک وب مرورگر، چون نام دامنه درون درخواست CONNECT به پروکسی فرستاده می‌شود. اما برنامه‌ها و مؤلفه‌های دیگر سیستم‌عامل که پروکسی برایشان تنظیم نشده، پرس‌وجوهای DNS خودشان را ادامه می‌دهند.

آیا در دستگاه‌های موبایل نشت WebRTC رخ می‌دهد؟#

ممکن است. مرورگرهای موبایل هم از WebRTC پشتیبانی می‌کنند و پروکسی وای‌فای تنظیم‌شده در گوشی فقط ترافیک HTTP را پوشش می‌دهد. تنظیم پروکسی در آیفون را در تنظیمات پروکسی آیفون توضیح داده‌ایم؛ همین آزمون WebRTC را در مرورگر موبایل هم می‌توانید اجرا کنید.

نشت را بستم، اما سایت هنوز می‌داند از پروکسی استفاده می‌کنم. چرا؟#

ممکن است خود آدرس IP متعلق به دیتاسنتر باشد، منطقه زمانی و زبان با موقعیت پروکسی ناسازگار باشند یا اثر انگشت مرورگر با بازدید قبلی شما یکی باشد. نشت شبکه فقط یکی از این نشانه‌هاست.

خلاصه#

پروکسی ترافیک HTTP مرورگر را جابه‌جا می‌کند؛ اتصال‌های UDP مربوط به WebRTC و برخی پرس‌وجوهای DNS ممکن است بیرون از این دامنه بمانند. نشت WebRTC را در کروم با سیاست WebRtcIPHandling و در فایرفاکس با تنظیمات media.peerconnection ببندید. برای نشت DNS در SOCKS5 از resolve از راه دور استفاده کنید و نتیجه را با آزمون کنسول تأیید کنید. سپس مطمئن شوید منطقه زمانی، زبان و کوکی‌ها با موقعیت پروکسی سازگارند. پلن‌های مناسب ترافیک مرورگر و برنامه را در خدمات پروکسی ما می‌یابید.