اینترنت فقط با برنامه VPN کار می‌کند؟ چهار لایه را بررسی کنید

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

کلاینت تنظیماتی را تغییر می‌دهد که تونل مالکشان نیست

یک کلاینت حریم خصوصی در ویندوز یا macOS معمولاً همزمان سه جا را دست می‌زند. پروکسی HTTP سیستم را تنظیم می‌کند، همان فیلدی که Internet Options نشان می‌دهد. یک آداپتور مجازی، اغلب درایور TAP، نصب می‌کند تا بتواند بسته‌ها را بگیرد. و فهرست resolver را بازنویسی می‌کند، در حالی که با زدن قطع اتصال فقط تونل ناپدید می‌شود.

افزونه مرورگر چیز محدودتری است. معمولاً پروفایل خودش یا پراکسی‌ای را که یک مرورگر دنبال می‌کند عوض می‌کند. به همین دلیل یک مرورگر می‌تواند از کار بیفتد در حالی که ابزارهای خط فرمان کار می‌کنند، یا برعکس: افزونه هرگز اختیار دست‌زدن به لایه‌های دیگر را نداشت. این که کدام لایه را ویرایش کرده، تعیین می‌کند کدام ابزارها خراب شوند.

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

سه بازمانده، سه خرابی متفاوت

بازمانده اول پراکسی‌ای است که به هیچ‌جا اشاره نمی‌کند: جعبه پراکسی LAN هنوز تیک خورده، یا آدرس یک اسکریپت پیکربندی به پورت localhost اشاره می‌کند که دیگر هیچ فرآیندی آنجا گوش نمی‌دهد. مرورگر هر درخواست را به آن پورت مرده می‌فرستد و آن‌قدر می‌ماند تا زمان انتظار شبیه شبکه مرده شود. دومی آداپتوری است که هنوز مالک یک مسیر پیش‌فرض است، چون دستگاه TAP-Windows یا درایور مسیریابی فروشنده پس از حذف نصب هم یک رابط واقعی می‌ماند. مسیری را که به آن داده شده نگه می‌دارد و ترافیک در تونلی که وجود ندارد ناپدید می‌شود. هیچ‌کدام از این دو خودشان را اعلام نمی‌کنند؛ هر دو دقیقاً مثل یک قطعی به نظر می‌رسند.

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

چهار لایه را از بالا به پایین بررسی کنید

از نزدیک‌ترین لایه به برنامه شروع کنید و پایین بیایید، چون لایه‌ها به همان ترتیب دیده‌شدن شکست می‌خورند. در هر آزمون یک لایه را تغییر دهید و بعد از هر کدام دوباره آزمون کنید. بازنشانی همه‌چیز با هم معمولاً مرور را برمی‌گرداند و شما را ناتوان می‌گذارد از گفتن این که کدام بازمانده باعثش بود، پس نصب بعدی همان معما را می‌سازد. ترتیب این است: پراکسی، آداپتورها، مسیرها، resolverها.

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

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

لینوکس و macOS فرمان‌های خودشان را می‌خواهند و این‌ها قابل جانشینی نیستند. در لینوکس مسیرها از ip route و resolver از resolvectl status می‌آید، جایی که systemd-resolved مالک آن است، با رجوع به cat /etc/resolv.conf. در macOS مسیرها از netstat -rn، resolverها از scutil --dns و پراکسی سیستم از scutil --proxy می‌آید. خواننده macOS که ip route را اجرا کند پیام command not found می‌گیرد و /etc/resolv.conf آنجا یک قطعه تولیدشده است نه پیکربندی مرجع. پیش از بررسی لایه، پلتفرم را بررسی کنید، وگرنه اولین فرمان خودش تبدیل به یافته می‌شود.

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

پراکسی تونل نیست

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

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

اگر می‌خواهید بدانید چنین کلاینتی واقعاً چه کرد، آن را مشاهده کنید نه داشبوردش را بخوانید. Process Monitor ثبت می‌کند به کدام کلیدهای رجیستری و فایل‌ها دست می‌زند، در حالی که گرفتن بسته‌ها نشان می‌دهد ترافیکش کجا رفت. هر دو ابزارهای معمولی‌اند و هر دو بهتر از هر چراغ وضعیتی به پرسش بازمانده پاسخ می‌دهند. هیچ‌کدام نیازی ندارند که برنامه هنوز در حال اجرا باشد.

جزء را بردارید، نه شواهد را

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

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

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