چرا دروازهٔ اسارت VPN شما را مسدود می‌کند و چگونه دوباره وارد شوید

در یک شبکهٔ باز، نقطهٔ دسترسی شما بسته‌ها را به‌سادگی به اینترنت نمی‌سپارد. یک نقطهٔ سیاست در بالادست بررسی می‌کند که آیا دستگاه شما مجاز شده است یا نه، و تا زمانی که مجاز نشود، تقریباً همه چیز دور ریخته می‌شود. کلاینت VPN شما آن سکوت را سرور مرده می‌خواند. به‌ندرت این را می‌گوید: WireGuard دست‌دادن را به خلأ تکرار می‌کند، OpenVPN از پایان مهلت اتصال خبر می‌دهد، و IKEv2 با خطای 809 دربارهٔ سروری دوردست که پاسخ نمی‌دهد برمی‌گردد.

دروازه در واقع چه چیزی را کنترل می‌کند

دروازهٔ اسارت دو چیز به‌هم‌چسبیده است: نقطهٔ تصمیم‌گیری سیاست و یک تغییردهندهٔ مسیر. وقتی دستگاه شما پیوند می‌گیرد و اجارهٔ DHCP می‌گیرد، شبکه شما را در وضعیت پیش از مجوز قرار می‌دهد.

آن وضعیت یک مجموعه قاعدهٔ دیوار آتش است. معمولاً DNS را مجاز می‌کند و HTTP یا HTTPS را به فهرست کوتاهی از میزبان‌های دروازه مجاز می‌کند، و هر چیز دیگر را دور می‌ریزد. فهرست مجاز همان باغ دیوارکشیده است و تقریباً هرگز نقطهٔ پایانی VPN را در بر نمی‌گیرد.

هیچ‌یک از این دورریختن‌ها مؤدبانه نیست. بسته‌هایی که به سرور VPN نشانه رفته‌اند به‌جای رد شدن دور ریخته می‌شوند، بنابراین کلاینت نه ICMP unreachable می‌گیرد و نه TCP reset، فقط نبود پاسخ. بسته به سازنده، تغییردهندهٔ مسیر ممکن است به درگاه 80 با تغییر مسیر به صفحهٔ ورود پاسخ دهد، در حالی که درگاه 443 دور ریخته یا رهگیری می‌شود. تغییر مسیرها آسان دیده می‌شوند چون یک پاسخ HTTP ساده حمل می‌کنند؛ رهگیری روی 443 به گواهی‌ای نیاز دارد که مرورگر شما از اعتماد به آن سر باز می‌زند.

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

چرا دست‌دادن VPN پیش از آغاز می‌میرد

هر پروتکل انتقال خودش را دارد، و دیوار آتش پیش از مجوز هر یک را به شکلی متفاوت می‌شکند. IKEv2 در Windows و iOS روی UDP 500 و UDP 4500 سوار می‌شود؛ دور ریخته شدن روی این درگاه‌ها به‌صورت 809 ظاهر می‌شود، یا به‌صورت شکستی از نوع حل نام روی کلاینت‌هایی که مراحل را جداگانه گزارش می‌کنند. OpenVPN روی UDP 1194 تا وقتی مهلتش تمام شود در وضعیت اتصال می‌ماند. OpenVPN روی TCP 443 مورد جالب است، چون دروازه می‌تواند دست‌دادن TCP را کامل کند و سپس با صفحهٔ تغییر مسیرش پاسخ دهد، بنابراین به‌جای پایان مهلت خطای TLS می‌بینید.

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

پلتفرم‌ها می‌کوشند وضعیت را پیش از VPN شما متوجه شوند. Windows نشانی URL شناخته‌شده‌ای را می‌گیرد تا تصمیم بگیرد اعلان ورود را نشان دهد یا نه، Android نقطهٔ پایانی را می‌خواهد که باید 204 No Content پاسخ دهد، و دستگاه‌های Apple پنجرهٔ کوچکی از شبکهٔ اسارت باز می‌کنند. این کاوش‌ها کار می‌کنند چون دروازه به‌جای بدنهٔ مورد انتظار با تغییر مسیر پاسخ می‌دهد. همین رفتار توضیح می‌دهد چگونه یک دروازه می‌تواند کاملاً سالم به نظر برسد در حالی که تونل شما مرده است: کاوش و تونل با قواعد متفاوتی داوری می‌شوند.

انقضای نشست در واقع چه چیزی را بازنشانی می‌کند

مکان‌ها نشست‌ها را به دلایلی بی‌ربط با حساب VPN شما منقضی می‌کنند: مهلت بی‌کاری، بیشترین طول نشست، اجارهٔ تازهٔ DHCP، یا پیوند دوباره به نقطهٔ دسترسی دیگر. وقتی زمان‌سنج عمل می‌کند، ورودی جدول نشست‌ها ناپدید می‌شود و مجموعه قواعد پیش از مجوز دقیقاً همان‌گونه که هنگام ورود بود بازمی‌گردد.

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

در آن نقطه، خطای کلاینت به شما می‌گوید در کدام مرحله هستید، اگر آن را با دقت بخوانید:

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

نخست وارد شوید، سپس تونل را بالا بیاورید

ترتیبی که کار می‌کند این است: دستگاه را مجاز کنید، مسیر را اثبات کنید، VPN را آغاز کنید، تونل را اثبات کنید، سپس مسدودسازی معمول خود را بازگردانید. آن گام آخر مهم است چون وضعیت موقتی که برای رسیدن به دروازه نیاز دارید دقیقاً همان وضعیتی است که یک کلید قطع برای جلوگیری از آن وجود دارد.

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

به ترتیب با ابزارهایی که همین حالا دارید بررسی کنید. پیش از تونل، کاوش را با سرآیندها و بدنهٔ هر دو دیدنی اجرا کنید و ببینید آیا انتقال VPN شما اصلاً پاسخی می‌گیرد:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

پیش از مجوز، یک دروازهٔ معمولی یکی از دو پاسخ را می‌دهد: 302 که Location آن به صفحهٔ ورود اشاره دارد، یا 200 با بدنهٔ HTML که همان صفحهٔ دروازه است. ثبت کنید کدام را گرفتید. تغییر مسیر پیش از ورود شکست نیست؛ دروازه دارد به شما می‌گوید کجا بروید. پس از آنکه دروازه موفقیت را گزارش کرد، فرمان را تکرار کنید و 200 را انتظار بکشید که بدنه‌اش واژهٔ تحت‌اللفظی Success است. همین رشته است که کاوش را معنادار می‌کند. اگر میزبان پیش از آنکه هرگز وارد شوید به‌طور عادی پاسخ دهد، در این شبکه هیچ دروازهٔ رهگیری وجود ندارد. در ضبط، دور ریخته شدن پیش از مجوز بسته‌های بیرون‌رونده‌ای است که چیزی از آن‌ها برنمی‌گردد، در حالی که مسیر کارآمد پاسخی به همان جریان در حدود یک ثانیه نشان می‌دهد. متصل شوید، سپس ضبط را تکرار کنید.

اگر تونل پس از بله گفتن دروازه همچنان شکست بخورد

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

شکست‌های دیگر در دستگاه زندگی می‌کنند. نشستی که هنوز به MAC قدیمی گره خورده، آداپتور Wi-Fi دومی با اجارهٔ خودش، یا کلاینتی که استثنای گواهی دروازه را ذخیره کرده، هر یک می‌تواند پس از مجوز تازهٔ پاک همچنان شکست بخورد. پیوند را قطع کنید، دوباره مجاز کنید و پیش از دست زدن به تنظیمات کلاینت یک بار تلاش کنید. اگر معماری پشت اجزایی را که می‌پایید می‌خواهید، خواندن RFC 8952 ارزش دارد.

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

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