عیب‌یابی

چگونه بفهمید چه چیزی اتصال شما را مسدود کرده است

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

6 دقیقه مطالعهآخرین بازبینی

از روی نشانه شروع کنید

شیوهٔ شکست یک اتصال خودش تشخیصی است. پیش از هر کاری آنچه می‌بینید را با این جدول تطبیق دهید.

حالت شکست در برابر علت محتمل
آنچه مشاهده می‌کنیدمحتمل‌ترین علتبخش
معلق می‌ماند و بعد بدون هیچ پاسخی منقضی می‌شودانداختن خاموش بسته‌ها، بر اساس نشانی یا پروتکلنشانی و پروتکل
وصل می‌شود و بعد پس از لحظه‌ای ناگهان قطع می‌شودبازنشانی‌های تزریقی TCP پس از دسته‌بندیبازنشانی‌ها
بی‌درنگ با خطای ترجمهٔ نام شکست می‌خورددستکاری DNSDNS
وصل می‌شود و برقرار می‌ماند اما غیرقابل‌استفاده کند استکاهش سرعت جریان دسته‌بندی‌شدهکاهش سرعت
روی دادهٔ همراه کار می‌کند اما روی وای‌فای نه (یا برعکس)سیاست مخصوص همان شبکه — این دو متفاوت فیلتر می‌کنندمقایسه
دیروز کار می‌کرد، چیزی تغییر نکرده، امروز مرده استنشانی نقطهٔ پایانی خارج از مسیر به فهرست سیاه رفتهنشانی و پروتکل

گام یک: آیا مشکل از DNS است؟

دستکاری DNS ارزان‌ترین شکل مسدودسازی و بنابراین رایج‌ترین است، و ساده‌ترین برای تأیید یا رد کردن. آزمون این است که یک پرسش را از دو حل‌کنندهٔ متفاوت بپرسید و مقایسه کنید.

  1. از حل‌کنندهٔ شبکهٔ خودتان بپرسید

    دستور `nslookup example.com` (ویندوز) یا `dig example.com` (مک‌اواس و لینوکس) را بدون آرگومان دیگری اجرا کنید تا از همان حل‌کننده‌ای استفاده کند که شبکه به شما داده است.

  2. مستقیماً از یک حل‌کنندهٔ عمومی بپرسید

    دستور `nslookup example.com 1.1.1.1` یا `dig @1.1.1.1 example.com` را اجرا کنید. این حل‌کنندهٔ خودِ شبکه را دور می‌زند، البته به شرط آنکه DNS خروجی اصلاً مجاز باشد.

  3. پاسخ‌ها را مقایسه کنید

    نشانی‌های متفاوت، پاسخ 0.0.0.0 یا 127.0.0.1، یا NXDOMAIN از یکی و پاسخ معتبر از دیگری، همگی نشانهٔ شنود هستند. پاسخ‌های یکسان DNS را از فهرست مظنونان خارج می‌کند.

  4. اگر پرسش دوم هم شکست خورد یا همان پاسخ نادرست را داد

    احتمالاً شبکه همهٔ ترافیک درگاه ۵۳ را به حل‌کنندهٔ خودش هدایت می‌کند، که رایج است. DNS رمزگذاری‌شده (DNS-over-HTTPS یا DNS-over-TLS) پادزهر آن است و بیشتر سیستم‌عامل‌ها اکنون به‌صورت بومی پشتیبانی‌اش می‌کنند.

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

گام دو: مسدودسازی نشانی یا مسدودسازی پروتکل؟

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

  1. درگاه را با یک اتصال سادهٔ TCP آزمایش کنید

    روی مک‌اواس یا لینوکس: `nc -vz <نشانی> 443`. روی ویندوز: `Test-NetConnection <نشانی> -Port 443`. این فقط یک اتصال خام TCP باز می‌کند و بس.

  2. نتیجه را تفسیر کنید

    اگر اتصال TCP موفق شود، نشانی و درگاه در دسترس‌اند و مشکل از پروتکلی است که روی آن‌ها صحبت می‌کنید — فیلتر ترافیک را دسته‌بندی کرده است. اگر خودِ TCP شکست بخورد، نشانی یا درگاه یکسره مسدود است.

  3. درگاه دومی را روی همان نشانی آزمایش کنید

    اگر ۴۴۳ شکست بخورد اما درگاه دیگری موفق شود، مسدودسازی مخصوص درگاه است. اگر همهٔ درگاه‌ها شکست بخورند، نشانی مسدود است.

  4. یک نقطهٔ پایانی متفاوت را آزمایش کنید

    اگر نشانی دیگری با همان تنظیمات و همان پروتکل کار کند، نشانی نخست در فهرست سیاه است و هیچ میزان تنظیم پروتکل آن را بازنمی‌گرداند.

این تفکیک ارزشمندترین چیز در این راهنماست. مسدودسازی نشانی نقطهٔ پایانی دیگری می‌طلبد. مسدودسازی پروتکل پروتکل یا ترابر دیگری می‌طلبد. به‌کاربردن درمان نادرست باعث می‌شود مشکل غیرقابل‌حل به نظر برسد.

گام سه: بازنشانی‌های تزریقی

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

  • تکرارپذیر و سریع است — معمولاً ظرف یکی دو ثانیه و هر بار در همان نقطه. خرابی‌های واقعی نامنظم‌اند.
  • طرف مقابل از آن بی‌خبر است. از دید سرور، کلاینت ناپدید شده است.
  • زمان‌بندی‌اش به دست‌دادن گره خورده نه به حجم: انتقال دادهٔ بیشتر آن را زودتر پیش نمی‌آورد.

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

درمان در سطح پروتکل است: دسته‌بند چیزی را شناخته، پس پاسخ، ترابری است که آنچه را شناخته ارائه نکند. عوض‌کردن نقطهٔ پایانی کمکی نمی‌کند، چون همان دسته‌بندی برای نقطهٔ پایانی جدید هم رخ خواهد داد.

گام چهار: کاهش سرعت

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

  1. تونل را اندازه بگیرید

    یک آزمون گذردهی از طریق تونل اجرا کنید و عدد را ثبت کنید، ترجیحاً چند بار طی چند دقیقه.

  2. در همان لحظه بدون آن اندازه بگیرید

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

  3. به شکل نگاه کنید، نه فقط به عدد

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

  4. درگاه و نقطهٔ پایانی دیگری را امتحان کنید

    اگر سقف صرف‌نظر از نقطهٔ پایانی به دنبال پروتکل بیاید، شکل‌دهی مبتنی بر دسته‌بندی است. اگر به دنبال نقطهٔ پایانی بیاید، احتمالاً مشکل ظرفیت در آن نقطهٔ پایانی است.

گام پنج: شبکه‌ها را مقایسه کنید

آموزنده‌ترین آزمون هیچ هزینه‌ای ندارد: همان پیکربندی را روی شبکه‌ای دیگر امتحان کنید — دادهٔ همراه به‌جای وای‌فای، یا یک شبکهٔ وای‌فای کاملاً متفاوت.

  • روی یک شبکه کار می‌کند و روی دیگری نه: سیاست متعلق به شبکه است، نه به دستگاه، پیکربندی یا نقطهٔ پایانی شما. هیچ‌چیز در سمت شما نیاز به اصلاح ندارد.
  • روی همهٔ شبکه‌ها شکست می‌خورد: مشکل از نقطهٔ پایانی، پیکربندی یا اعتبارنامه‌هاست و باید همان‌جا را بگردید.
  • روی هر دو کار می‌کند اما روی یکی کند است: آن شبکه در حال شکل‌دهی است، نه مسدودسازی.

یادداشت نگه دارید

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

پرسش‌های پرتکرار

VPN من وصل می‌شود اما هیچ سایتی بارگذاری نمی‌شود. مشکل چیست؟

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

چطور بفهمم ISP من سرعت VPN را کاهش می‌دهد؟

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

چرا VPN من روی دادهٔ همراه کار می‌کند اما روی وای‌فای نه؟

چون این‌ها شبکه‌های متفاوتی با سیاست‌های فیلترینگ متفاوت‌اند. این نتیجهٔ سودمندی است نه یک خرابی: به شما می‌گوید مشکل سیاست شبکهٔ وای‌فای است، نه پیکربندی یا نقطهٔ پایانی شما، و هیچ‌چیز روی دستگاهتان نیاز به تغییر ندارد.

آیا تغییر درگاه یک VPN مسدودشده را درست می‌کند؟

تنها اگر مسدودسازی مبتنی بر درگاه بوده باشد، که می‌توانید با آزمون اتصال سادهٔ TCP روی چند درگاه تأییدش کنید. اگر درگاه در دسترس باشد اما پروتکل شما روی آن انداخته شود، تغییر درگاه چیزی را عوض نمی‌کند، چون دسته‌بندی پس از باز شدن اتصال رخ می‌دهد.

HushTunnel این‌ها را چگونه به کار می‌گیرد

HushTunnel از VLESS به همراه REALITY و XTLS استفاده می‌کند — همان طراحی‌هایی که در این راهنماها شرح داده شده‌اند — و هیچ سابقه‌ای از سایت‌هایی که بازدید می‌کنید نگه نمی‌دارد.

همهٔ راهنماها