OpenVPN در وای‌فای هتل وصل نمی‌شود؟ TCP 443 را امتحان کنید

کلاینت را باز کنید، Connect را بزنید و به‌جای کادر محاوره‌ای بعد از آن، خط وضعیت را بخوانید. پروفایلی که پس از شبکه هتل، دانشگاه یا موبایل روی Connecting یا Waiting for server متوقف می‌شود معمولاً لایه انتقال خود را جایی در مسیر از دست داده است، نه اعتبارنامه‌هایش. قدم مفید بعدی این است که پیش از دست زدن به سرور بدانید آن شبکه چه چیزی را حمل می‌کند. تا وقتی همان پروفایل جای دیگری کار نکرده است چیزی را تغییر ندهید.

ابتدا از هات‌اسپات گوشی آزمایش کنید. اگر تونل آنجا بالا بیاید، سرور، گواهی و حساب همه سالم‌اند و تنها متغیر باقی‌مانده شبکه‌ای است که پیش روی شماست.

از کلاینت شروع کنید: خط وضعیت را بخوانید

خط وضعیت می‌گوید کدام مرحله شکست خورده است. کلاینتی که روی Connecting گیر کرده هنوز نام میزبان را حل می‌کند یا سوکت بیرونی را باز می‌کند؛ کلاینتی که به Waiting for server می‌رسد مسیر دارد اما پاسخی ندارد؛ کلاینتی که احراز هویت می‌کند و سپس قطع می‌شود مشکل کاملاً دیگری دارد. گزارش کلاینت و فیلدهای remote و proto خود پروفایل نشان می‌دهند کلاینت چه کاری می‌خواهد بکند، و --verb 4 در کلاینت خط فرمان همین جزئیات را چاپ می‌کند. مقایسه آن با شبکه‌ای که پیش روی شماست همان چیزی است که «VPN مسدود است» را به یک ادعای مشخص تبدیل می‌کند.

سپس شبکه را با ابزارهایی که از قبل دارید بررسی کنید. nc -vzu 203.0.113.10 1194 یک دیتاگرام UDP می‌فرستد، curl -v telnet://203.0.113.10:443 گزارش می‌دهد که آیا دست‌دهی TCP کامل می‌شود، و مرورگری که صفحه HTTPS بار می‌کند فقط ثابت می‌کند که 443 خروجی به همان یک میزبان می‌رسد. بررسی‌های کوچک به چیزی پاسخ می‌دهند که کلاینت VPN نمی‌تواند: کدام پورت و پروتکل اصلاً از این شبکه خارج می‌شوند.

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

شنونده و پروفایل را با هم جابه‌جا کنید

در سمت سرور، شنونده را روی چیزی تنظیم کنید که شبکه اجازه می‌دهد: port 443 و proto tcp در پیکربندی سرور، سپس سرویس را دوباره راه‌اندازی کنید و سوکت را با ss -lntp تأیید کنید. در سمت کلاینت، پروفایل باید همگام باشد، چون لایه انتقال و پورت بیرون از تونل قرار دارند: proto tcp و port 443 در فایل .ovpn، یا فیلدهای متناظر در صفحه تنظیمات برنامه. پروفایلی که هنوز UDP 1194 را هدف گرفته دقیقاً مثل قبل شکست می‌خورد، و وسوسه آن است که دیوار آتش را سرزنش کنید که پیش‌تر درست شده است. اگر همان میزبان در 443 به HTTPS هم پاسخ دهد، دو شنونده نمی‌توانند آن نشانی و پروتکل را شریک شوند؛ به VPN نشانی دومی بدهید یا یک جداکننده چندگانه جلوی آن بگذارید.

اولین اتصال را با tcpdump -ni any port 443 در هر دو طرف دنبال کنید. بسته‌هایی که از کلاینت خارج می‌شوند و هرگز نمی‌رسند یعنی شبکه با این حال فیلتر می‌کند، یا نشانی موجود در پروفایل آنی نیست که فرض می‌کنید. بسته‌هایی که بدون پاسخ می‌رسند شما را به گزارش سرور برمی‌گردانند، جایی که ناسازگاری پروتکل بی‌درنگ به‌صورت بسته حذف‌شده دیده می‌شود.

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

برخی شبکه‌های مهمان چیزی جز پروکسی HTTP را مجاز نمی‌دانند، که محدودیتی متفاوت از پورت بسته است و بیش از OpenVPN را کنار می‌گذارد. کلاینت‌هایی که فقط PPTP یا L2TP/IPsec یا IPsec خالی را می‌فهمند راهی برای عبور از آن ندارند، چون آن طراحی‌ها انتظار دارند پروتکل بیرونی‌شان مستقیم به سرور برسد. OpenVPN می‌تواند، با http-proxy proxy.example.net 8080 در پروفایل کلاینت، به شرطی که پروکسی روش CONNECT را به پورت شما اجازه دهد. پروکسی SOCKS حتی آسان‌تر است، چون جریان را بدون اهمیت دادن به محتوای درونش عبور می‌دهد.

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

هزینه جایگزین را پیش از نگه داشتنش حساب کنید

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

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