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

تأیید کنید آزمون واقعاً چه چیزی را سنجید

نشانی‌ای که در پنجرهٔ Wi-Fi یا Ethernet نشان داده می‌شود نشانی رابط در بخش خودتان است، نه نشانی‌ای که یک وب‌سایت می‌بیند، پس می‌تواند یکسان بماند در حالی که تونل بی‌نقص کار می‌کند. مکان باز هم نشانهٔ جداگانه‌ای است: منطقهٔ حساب ذخیره‌شده یا خواندن مکان‌یابی مجاز با تغییر خروج جابه‌جا نمی‌شود، و ورودی که شما را از قبل می‌شناسد هم نه.

از پژواک نشانی عمومی استفاده کنید و از هر خانواده جداگانه بپرسید، چون نتیجهٔ آزمون دوپشته مورد جالب را پنهان می‌کند:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

هر دو را پیش و پس از اتصال اجرا کنید. اگر پاسخ IPv4 به نشانی خروج تغییر کرد و پاسخ IPv6 نکرد، تونل خرابی ندارید؛ یک خانواده بیرون از آن سفر می‌کند. اگر هر دو پاسخ یکسان ماندند، درخواست هرگز به تونل نرسید و بقیهٔ اینجا صادق است.

پروفایل ممکن است فقط بخشی از ترافیک را پوشش دهد

پروفایل تونل تفکیک‌شده پاسخ رایج است و نقص نیست. OpenVPN همه چیز را فقط زمانی از تونل می‌فرستد که redirect-gateway در گزینه‌های ارسالی باشد؛ بدون آن کلاینت چند مسیر مشخص می‌گیرد و مسیر پیش‌فرض شما روی پیوند فیزیکی می‌ماند. در Windows همان کلید به‌صورت «استفاده از دروازهٔ پیش‌فرض در شبکهٔ راه دور» در ویژگی‌های IPv4 آداپتور ظاهر می‌شود، و برداشتن آن انتخابی آگاهانه است که از هر اتصال دوباره جان سالم به در می‌برد.

دامنهٔ هر برنامه لایهٔ دوم است. تنظیم VPN هر برنامه در Android تعیین می‌کند کدام برنامه‌ها شامل شوند، پس کلید VPN در نوار وضعیت ثابت نمی‌کند که مرورگر درون آن است. افزونهٔ مرورگری که ترافیک خودش را پروکسی می‌کند تصویر آینه‌ای می‌سازد: مرورگر نشانی خروج را نشان می‌دهد در حالی که یک کلاینت ایمیل یا بازی روی همان دستگاه هنوز نشانی شما را نشان می‌دهد. همان درخواست را در دو برنامه مقایسه کنید. اگر یکی تغییر کند و دیگری نه، به دامنه نگاه می‌کنید، نه به تونل خراب.

یک خانوادهٔ نشانی هنوز می‌تواند مستقیم برود

بیشتر پروفایل‌های VPN برای IPv4 نوشته شده‌اند، و بسیاری هنوز چنین‌اند. در شبکهٔ دوپشته تونل برای IPv4 نشانی 10.8.0.x را می‌گیرد در حالی که پیوند فیزیکی یک نشانی سراسری IPv6 و یک مسیر پیش‌فرض نگه می‌دارد، پس سایتی که IPv6 را پشتیبانی می‌کند مستقیم می‌رسد و نشانی‌ای که گزارش می‌کند نشانی ارائه‌دهندهٔ شماست. این نشت با تونل IPv4 سالم است، و برای آزمونی که فقط IPv4 حرف می‌زند نامرئی است.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

رابط را در هر پاسخ بخوانید. اگر جست‌وجوی IPv6 دستگاه Ethernet یا Wi-Fi شما را نام می‌برد در حالی که جست‌وجوی IPv4 تونل را نام می‌برد، سیاست آن خانواده غایب است نه خراب. خاموش کردن IPv6 در کل دستگاه نشانه را از میان می‌برد و تصمیم را پنهان می‌کند؛ بهتر است پوشش پروفایل را درست کنید یا خانواده را فقط روی همان اتصال غیرفعال کنید، و بنویسید کدام یک از دو را انتخاب کردید.

مسیر دومی می‌تواند جست‌وجو را ببرد

یک پروکسی رقیب، یک کلاینت VPN دوم، یک آداپتور مجازی از کانتینر یا ابزار رومیزی راه دور، یا یک مسیر اضافی برای همان پیشوندی که می‌سنجید، همه می‌توانند اولویت بگیرند. مسیر مشخص همیشه بر مسیر پیش‌فرض پیروز می‌شود، پس /24 باقی‌مانده برای سایتی که می‌سنجید، که به دروازهٔ LAN شما اشاره می‌کند، آن ترافیک را بیرون از تونل می‌فرستد هر قدر هم تونل سالم باشد.

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

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

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

با یک درخواست تازه دوباره بسنجید

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

دو نتیجه را جدا نگه دارید. اگر نشانی تغییر کرد اما یک سایت هنوز شما را رد می‌کند، تونل کار می‌کند و سایت نشانی مرکز داده را رد می‌کند؛ آن مشکلی دیگر با پاسخی دیگر است. اگر نشانی هرگز تغییر نمی‌کند، چهار پرسش را به ترتیب کار کنید: آزمون کدام نشانی را چاپ کرد، کدام خانواده بود، کدام برنامه درخواست را کرد، و آن درخواست از کدام مسیر رفت. مستندات Microsoft دربارهٔ تصمیم‌های مسیریابی VPN توضیح می‌دهد که کلاینت Windows چگونه میان تونل و آداپتور فیزیکی انتخاب می‌کند وقتی هر دو مسیر دارند.

مقالات مرتبط