VPN وصل است اما اینترنت نیست؟ چهار لایه را بررسی کنید

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

از شبکه‌ای که از آن آمده‌اید شروع کنید

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

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

تشخیص دهید که شکست مربوط به تجزیه نام است

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

nslookup example.com

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

تونل کامل یا فقط زیرشبکه‌های شرکت

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

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

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

وقتی سرور هرگز چیزی را هدایت نمی‌کند

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

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

گزارش کلاینت را پس از ورود برای شکست در اعمال مسیرها، تنظیمات DNS یا آداپتور مجازی بررسی کنید. خطاهای آن مرحله به دستگاه اشاره دارند نه به سرور. خطایی که هرگز در گزارش ظاهر نمی‌شود هم به همان اندازه گویاست، زیرا سوءظن را به سمت دور می‌برد.

هر بار یک لایه را بررسی کنید

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

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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