نشت DNS، پورت‌های باز و اثر انگشت TLS

ابزار عبور از فیلترینگ ترافیک HTTP شما را در یک تونل رمزشده می‌پیچد، و همین بخش است که همه حواسشان به آن است. اما پیش از آنکه بتوانید به سایتی وصل شوید، مرحلهٔ زودتری هست — تبدیل نام به نشانی — که اغلب بیرون از تونل اتفاق می‌افتد. به همان اندازه فراموش‌شدنی: دستگاه خودتان چه درهایی به روی اینترنت باز دارد، و آیا خود دست‌دهی رمزشده زیادی حرف می‌زند. این سایت هر سه را بررسی می‌کند: پورت‌ها در صفحهٔ IP، و DNS و TLS هر کدام در صفحهٔ خودشان در آزمایشگاه اثر انگشت. دو مورد آخر به یک استقرار جداگانه وابسته‌اند، پس روی بعضی نصب‌ها به‌جای نتیجه «پیکربندی نشده» می‌بینید؛ در هر حال سازوکاری که در ادامه می‌آید می‌گوید باید به چه چیزی نگاه کنید.

نشت DNS چطور اتفاق می‌افتد

برای رسیدن به example.com، مرورگر ابتدا از resolver سیستم می‌پرسد این نام به کدام IP نگاشته می‌شود. با پروکسی فعال، این پرسش باید توسط resolverی در انتهای دور تونل پاسخ داده شود. نشت یعنی چنین نشده و پرسش مستقیم به DNS اپراتور محلی شما رفته است.

این کار به چند شکل خراب می‌شود. رایج‌ترین: ابزار اتصال‌های TCP را می‌گیرد، اما سیستم از روی عادت همچنان پرس‌وجوهای UDP پورت 53 را به ISP می‌فرستد. Windows با حل موازی یک پیچ اضافه دارد: از همهٔ رابط‌های شبکه هم‌زمان پرسیده می‌شود و اولین پاسخ برنده است، پس اگر تونل کمی کندتر باشد، می‌بازد. IPv6 یک سوراخ کلاسیک دیگر است: ابزار فقط IPv4 را پروکسی می‌کند، در حالی که جستجوها و اتصال‌های IPv6 دست‌نخورده از ISP عبور می‌کنند. و برخی اپراتورها ربایش شفاف انجام می‌دهند؛ همهٔ ترافیک پورت 53 را در دروازه می‌گیرند و صرف‌نظر از تنظیمات شما خودشان پاسخ می‌دهند.

پیامدها در دو لایه می‌آید. لایهٔ حریم خصوصی: محتوا رمز شده، اما ISP و هر کسی پشت آن نشسته، هر دامنه‌ای را که جستجو کرده‌اید می‌داند، و همین فهرست به‌تنهایی حرف زیادی می‌زند. لایهٔ دوم در چین بیشتر گاز می‌گیرد. یک پاسخ DNS مسموم، IP اشتباهی به شما می‌دهد؛ لاگ ابزار می‌گوید «متصل شد»، اما اتصال به نشانی‌ای رفته که به هیچ‌جا نمی‌رسد، و صفحه هرگز بارگذاری نمی‌شود. بخش بزرگی از پرسش‌های «چرا با اینکه پروکسی روشن است کار نمی‌کند» به همین‌جا برمی‌گردد.

تشخیص چطور کار می‌کند

ترفند تشخیص ظریف است. سایت آزمایش، سرور DNS معتبر یک دامنه را در اختیار دارد. وقتی صفحه بارگذاری می‌شود، یک زیردامنهٔ یک‌بارمصرف می‌سازد — مثلاً k3f9a2.dnsleak.example — و از مرورگر می‌خواهد آن را واکشی کند. هیچ‌کس هرگز آن نام را cache نکرده، پس جستجو باید تمام راه را تا سرور معتبر برود. سرور ثبت می‌کند چه کسی پرسیده، و resolverی که پرسیده همان خروجی DNS شماست. اگر متعلق به ISP شما باشد، نشت دارید؛ اگر متعلق به ارائه‌دهندهٔ VPN یا یک resolver عمومی باشد، ندارید.

صفحهٔ نشت DNS در آزمایشگاه اثر انگشت این سایت دقیقاً همین کار را می‌کند. مرورگر شش نام میزبان یک‌بارمصرف را زیر zoneی حل می‌کند که این سایت سرور معتبر آن است؛ سرور DNS ما ثبت می‌کند هر نام را کدام resolver پرسیده، و صفحه آن resolverها را همراه با ASN و کشور فهرست می‌کند و اگر حتی یکی از آن‌ها در کشوری غیر از کشور IP خروجی شما باشد، نشت اعلام می‌کند. تنها پیش‌نیاز، یک zone در DNS است که به این سایت واگذار شده باشد، و این یک استقرار جدا از خود وب‌سایت است. روی نصبی که این zone تنظیم نشده، صفحه به‌جای حدس زدن صریحاً می‌نویسد «پیکربندی نشده».

هر چه نشان داد، ارزش دارد نتیجه را با یک سرویس بیرونی هم بسنجید: ipleak.net، dnsleaktest.com، یا صفحهٔ dns-leak در browserscan. در هر نتیجه‌ای دو چیز را بررسی کنید. resolverهای فهرست‌شده نباید متعلق به ISP محلی شما باشند. در حالت ایده‌آل، resolver و IP خروجی در یک کشورند. خروجی هنگ‌کنگ در کنار resolver پکن از China Telecom، نمونهٔ کتاب درسی نشت است.

بستن نشت

در سطح ابزار، بیشتر کلاینت‌های مدرن گزینهٔ «remote DNS» یا چیزی شبیه آن دارند: حالت fake-ip در کلاینت‌های خانوادهٔ Clash، قواعد مسیریابی DNS در sing-box. ایده یکی است — یا حل نام هم از تونل عبور کند، یا به‌صورت محلی یک IP جایگزین برگردانده شود و جستجوی واقعی به سمت خروجی واگذار شود. آن را فعال کنید و نشت عمدتاً متوقف می‌شود.

در سطح سیستم، می‌توانید به DoH (DNS over HTTPS) سوئیچ کنید تا خود پرس‌وجوها رمز شوند و ISP نه بتواند بخواندشان و نه مسمومشان کند؛ البته نقاط پایانی DoH در برخی شبکه‌ها مسدودند، پس آزمون و خطا لازم دارد. IPv6 یا باید غیرفعال شود یا ابزار صریحاً آن را مدیریت کند؛ نگذارید مسیری باشد که از دست در می‌رود. یک تلهٔ رایج دیگر حالت «پروکسی فقط برای مرورگر» است، که در آن مرورگر از تونل استفاده می‌کند اما هیچ‌چیز دیگری در سیستم نه — از جمله DNS.

چرا پورت‌های 22 و 3389 ارزش نگاه کردن دارند

صفحهٔ IP این سایت یک اتصال خروجی از سرور ما به IP عمومی شما روی پورت 22 (SSH) و 3389 (RDP) برقرار می‌کند، با مهلت دو ثانیه، و باز، بسته یا filtered را گزارش می‌دهد. چرا فقط این دو؟ چون معنایشان کمترین ابهام را دارد.

از بیرون که نگاه کنیم، یک شبکهٔ خانگی باید هر دو را بسته یا توسط فایروال دورانداخته داشته باشد. اگر یکی باز نشان داده شود، معمولاً یکی از این دو معنا را دارد: مرورگر را روی یک سرور ابری یا VPS اجرا می‌کنید (مثلاً با remote desktop به آن وصل شده‌اید)، یا روتر خانگی‌تان port forwarding دارد. اولی رایج است؛ خیلی‌ها دقیقاً برای داشتن یک IP «پاک» یک دسکتاپ داخل VPS خارج از کشور اجرا می‌کنند.

مشکل در نحوهٔ خواندن موتورهای ریسک است. دیدگاه browserscan این است که «IP کاربر» با پورت 3389 باز، به پلتفرم می‌گوید این یک ماشین از راه دور اداره‌شده است نه رایانهٔ یک شخص، و برخی پلتفرم‌ها واقعاً آن را شاهدی بر farm یا یک راه‌اندازی خودکارسازی تلقی می‌کنند و سپس محدود یا مسدود می‌کنند. ما دربارهٔ منصفانه بودنش قضاوت نمی‌کنیم؛ فقط می‌گوییم این سیگنال واقعی است.

این را هم بدانید: اگر پشت CGNAT هستید (دادهٔ موبایل، برخی اینترنت‌های خانگی)، ما به دروازهٔ اپراتور وصل می‌شویم نه دستگاه شما، و نتیجه هیچ معنایی ندارد.

اثر انگشت TLS: دست‌دهی شما را لو می‌دهد

و در نهایت، بررسی‌ای که هر سال مهم‌تر می‌شود. وقتی مرورگر یک اتصال HTTPS باز می‌کند، اولین بسته ClientHello است که نسخه‌های TLS پشتیبانی‌شدهٔ کلاینت، مجموعه‌های رمز به ترتیب اولویت، افزونه‌ها و ترتیبشان، و منحنی‌های بیضوی و قالب‌های نقطهٔ پشتیبانی‌شده را فهرست می‌کند. برای هر کلاینت مشخص این ترکیب نسبتاً ثابت است: Chrome ترتیب خودش را دارد، Firefox ترتیب دیگری، و کتابخانهٔ requests در Python باز هم متفاوت به نظر می‌رسد. این فیلدها را به هم بچسبانید و با MD5 هش کنید تا اثر انگشت JA3 به دست آید. JA4 قالب جدیدتر است؛ ساختاریافته‌تر و مقاوم‌تر در برابر تصادفی‌سازی. HTTP/2 هم معادلی دارد: مقادیر فریم SETTINGS، WINDOW_UPDATE و ترتیب فیلدهای pseudo-header، که Akamai آن را در قالب اثر انگشت h2 رسمیت داد.

کاربردش مستقیم است. درخواستی که User-Agent آن می‌گوید Chrome اما دست‌دهی TLS آن شبیه کتابخانهٔ استاندارد Go است، تقریباً به یقین یک اسکریپت است. این یکی از قابل اتکاترین راه‌های دیدن پشت یک UA جعلی است و سیستم‌های ضدربات و ضدتقلب به‌شدت به آن تکیه می‌کنند.

برای کاربران فیلترشکن ربطش این است: برخی پروکسی‌ها و relayها TLS را در میانه خاتمه می‌دهند و یک دست‌دهی تازه شروع می‌کنند، پس سرور اثر انگشت آن‌ها را می‌بیند، نه اثر انگشت مرورگر شما را. برخی ابزارها عمداً اثر انگشت Chrome را تقلید می‌کنند تا از مسدودسازی بگریزند. برای اینکه اصلاً چیزی از این‌ها دیده شود، سرور باید خودش TLS را خاتمه دهد؛ پشت لبهٔ یک CDN فقط دست‌دهی خود CDN دیده می‌شود. به همین دلیل صفحهٔ TLS این سایت یک درخواست cross-origin به یک نام میزبان جداگانه و بدون CDN می‌فرستد که دست‌دهی همان‌جا خاتمه می‌یابد، و JA3، JA4 و اثر انگشت HTTP/2 را گزارش می‌کند؛ به‌علاوه بر اساس آمار خود سایت می‌گوید آیا این JA4 همان چیزی است که معمولاً از خانوادهٔ مرورگری می‌بینیم که User-Agent شما ادعا می‌کند. وقتی آن نقطهٔ پایانی مستقر نشده یا از شبکهٔ شما در دسترس نیست، صفحه به سرویس ثالث check.ja3.zone برمی‌گردد که فقط JA3 می‌دهد و مقایسه‌ای در کار نیست.

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

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

«filtered» برای یک پورت یعنی چه؟ هیچ پاسخی ظرف دو ثانیه نیامده؛ معمولاً یک فایروال بسته را دور می‌اندازد. برای شبکهٔ خانگی این عادی است، حتی مطلوب.

چرا صفحهٔ DNS یا TLS می‌گوید «پیکربندی نشده»؟ هر دو بررسی به چیزی بیرون از خود وب‌اپ نیاز دارند: یکی به یک zone در DNS که به سایت واگذار شده باشد، دیگری به میزبانی که خودش TLS را خاتمه دهد. اگر روی یک استقرار این‌ها راه‌اندازی نشده باشد، صفحه همین را می‌گوید نه اینکه حدس بزند؛ صفحهٔ TLS در این حالت همچنان یک JA3 از check.ja3.zone نشان می‌دهد.

می‌شود JA3 را جعل کرد؟ بله. برخی کتابخانه‌ها به‌طور خاص دست‌دهی مرورگرهای رایج را تقلید می‌کنند، که بخشی از دلیل وجود JA4 است. اما جعل سازگار آن در همه‌جا آسان نیست و همچنان سیگنال مفیدی است.