چرا یک پروفایل OpenVPN در خانه کار میکند اما در هتل شکست میخورد
همان پروفایل، شبکه متفاوت: یک پورتال ورود، یک پورت UDP فیلترشده، یک زیرشبکه همپوشان یا APN فقط IPv6 میتواند تونل را پیش از آغاز متوقف کند.
وایفای دفتر و اتاق هتل میتوانند به یک لپتاپ دو شبکه کاملاً متفاوت بدهند، و پروفایل میان آن دو هیچ اطلاعی از این ماجرا ندارد. آنچه در خانه کار میکند، یک اتصال بالاسری سهلگیر، حل نام سالم و زیرشبکه محلیای را فرض میکند که با هیچچیزِ حملشده توسط تونل تصادم نکند. هر یک از این فرضها میتواند بهطور مستقل شکست بخورد.
راه سودمند برای اشکالزدایی این است که شبکه را چهار واقعیت جداگانه بگیریم و سپس به ترتیب آزمون کنیم. حدس زدن درباره پروفایل در ابتدا معمولاً تغییری میسازد که هیچچیز را درست نمیکند و شواهد را پنهان میکند.
چهار واقعیت شبکه بین مکانها تغییر میکند
واقعیت اول این است که آیا شبکه محلی اصلاً شما را بیرون میگذارد. پورتال ورود یک دستگاه را به صفحه ورود میپذیرد و تا تکمیل آن صفحه همهچیز دیگر را مسدود میکند، یعنی تونل نمیتواند شروع شود، هرقدر هم پروفایل درست باشد.
واقعیت دوم حل نام است. پورتالی که DNS را رهگیری میکند به هر پرسوجو با نشانی خودش پاسخ میدهد، پس نام میزبان VPN به پورتال تفکیک میشود و کارخواه میکوشد تونلی به یک صفحه وب بسازد.
واقعیت سوم پالایش ترابری است. شبکههایی که فقط مرورگری را مجاز میکنند، TCP 443 را به مقصدهای دلخواه عبور میدهند و تقریباً هر چیز دیگری از جمله UDP را دور میریزند.
واقعیت چهارم آدرسدهی است. ممکن است زیرشبکه محلی با شبکهای پشت تونل همپوشان شود، یا اتصال بالاسری هیچ مسیر قابل استفاده IPv4 ارائه نکند.
حل نام و پورتال ورود
نام میزبان را در پروفایل با نشانی عددی سرور جایگزین کنید و دوباره امتحان کنید. اگر IP وصل شود و نام نه، ایراد از حل نام است و خود پروفایل سالم است.
پیش از دست زدن به VPN یک مرورگر باز کنید و یک صفحه HTTP معمولی را امتحان کنید. تغییرمسیر به صفحه ورود یعنی پورتال هنوز معلق است؛ آن را کامل کنید و سپس دوباره وصل شوید. بسیاری از هتلها نشست را پس از چند ساعت منقضی میکنند، که مانند قطعی میانروز به نظر میرسد نه مشکل ورود.
اگر نشانی عددی هم شکست خورد، حل نام توضیح نیست، پس به ترابری بروید. نشانیای را که آزمودید نگه دارید، چون به بررسی بعدی میگوید بستهها اصلاً ماشین را ترک کردهاند یا نه.
پالایش ترابری: نخست UDP، سپس TCP 443 بهعنوان جایگزین
جریان OpenVPN روی UDP 1194 شبیه هیچچیزِ شناختهشده برای فایروال هتل نیست، پس بدون خطا دور ریخته میشود. کارخواه تا پایان مهلت خود دوباره تلاش میکند و کاربر بهجای رد شدن، اتصالی را میبیند که هرگز برقرار نمیشود. فایروالهایی که چنین رفتار میکنند بهندرت دورریختن را جایی قابل مشاهده ثبت میکنند. نبودِ رد شدن خودِ نشانه است.
TCP 443 جایگزین قابلاعتماد است، چون شبکه نمیتواند آن را از HTTPS معمولی تشخیص دهد. وقتی پروفایل TCP وجود دارد از همان استفاده کنید، زیرا سرور هم باید روی آن ترابری و پورت گوش دهد؛ تغییر تنها کارخواه نوع دیگری از شکست را میسازد. اگر پروفایل TCP وجود ندارد، بهجای ساختن یکی با ویرایش پورت، از اپراتور بپرسید. سمت سرور هم باید موافق باشد و ناسازگاری دوباره مانند مشکل فایروال به نظر میرسد.
انتظار هزینه کارایی داشته باشید. TCP درون TCP بازفرستها را روی پیوند پرخطا تشدید میکند، پس تونل TCPی که کار میکند ممکن است در شبکه شلوغ هتل هنوز کند احساس شود. این معاملهای برای دسترسیپذیری است، نه نقصی برای تعقیب.
تصادم نشانیها و اتصالهای بالاسری بدون IPv4
تونل میتواند برقرار شود و باز هم چیزی حمل نکند. وقتی LAN محلی و شبکهای راه دور پیشوندی مانند 192.168.1.0/24 را شریک میشوند، کارخواه میزبان دور را مستقیم متصل میپندارد و بسته را بهجای تونل به پیوند محلی میفرستد. نشانه، اتصال موفق با یک زیرشبکه دسترسناپذیر است که آسان به مشکل مسیر سمت سرور تعبیر میشود.
راهحل دائمی انتقال LAN دور به یک بازه خصوصی نامتعارف است. انتخاب بازهای که هیچکس در خانه استفاده نمیکند، مانند 10.42.0.0/24، مشکل را برای هر مکان آینده نه فقط یک مکان جلوگیری میکند. چاره محلی کنار آمدن از آن هتل، هاتاسپات یا روتر است که اصلاً راهحل نیست.
اتصالهای بالاسری موبایل دو تنوع اضافه میکنند. NAT در سطح اپراتور یعنی اتصالهای ورودی نمیرسند، که اگر سرور میزبانی میکنید مهم است ولی برای کارخواه خروجی نه. APN پیکربندیشده بهصورت فقط IPv6 با ترجمه NAT64 میتواند کارخواهی را که بر مسیر واقعی IPv4 پافشاری میکند شکست دهد، و درمان معمول تغییر پروتکل APN به IPv4 یا دوپشته است.
نشانهها پس از برپا شدن تونل
تونلی که وصل میشود و سپس ساکت میماند معمولاً مشکل keepalive یا MTU است، نه پورت مسدود. اتصالی که پس از شمار ثابتی دقیقه میافتد به تایمر keepalive یا مذاکره دوباره اشاره دارد. کارخواه را طوری تنظیم کنید که همتا را کاوش کند و با ایست پاسخها دوباره شروع کند، و اگر پینگها موفقاند ولی انتقالهای بزرگ میایستند، MTU کوچکتر تونل را بیازمایید.
پیش از درخواست کمک سه چیز را بنویسید: نشانیای که آزمودید و اینکه پاسخ داد یا نه، ترابری و پورتی که بهکار بردید، و زیرشبکه محلی شبکهای که شکست خورد. اینها با هم حل نام را از پالایش ترابری و از تصادم نشانی جدا میکنند، و اینها همان علتهایی هستند که در برخورد با شواهد دوام میآورند.