VPN در شبکه‌ای که فقط وب را مجاز می‌کند مسدود شده؟ لایه‌ها را بررسی کنید

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

ثابت کنید کدام لایه اتصال را رد می‌کند

با کلاینت VPN شروع نکنید. با یک درخواست HTTPS ساده به همان میزبان شروع کنید و فازهای زمان را بخوانید، زیرا فازی که شکست می‌خورد می‌گوید کدام دستگاه مسئول است:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

اکنون گواهی‌ای را که واقعاً می‌گیرید بررسی کنید. این سریع‌ترین راه برای فهمیدن این است که با سرور صحبت می‌کنید یا با جعبه میانی که نشست را دوباره امضا کرده:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

کلاینت آگاه به پروکسی بسته اول را تغییر می‌دهد، نه سیاست را

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

درگاه 443 قابل دسترسی است، نه مجاز

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

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

UDP معمولاً اولین قربانی است و شایسته تأیید است، نه حدس. اگر WireGuard یا OpenVPN پیش‌فرض هرگز مصافحه را کامل نکرد در حالی که TCP 443 کار می‌کند، شبکه UDP را می‌ریزد و هیچ بازتولید کلیدی آن را تغییر نمی‌دهد:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

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

بررسی کنید واقعاً چه چیزی دستگاه را ترک کرد

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

اگر بسته‌های SYN می‌بینید و SYN-ACK نیست، مسدودسازی بالادست است و کلاینت بی‌گناه. اگر مصافحه کامل به نشانی می‌بینید که نشانی سرور نیست، با پروکسی یا رهگیر صحبت می‌کنید. اگر هیچ نمی‌بینید، پیش از هر نتیجه‌گیری بررسی کنید روی رابط درست ضبط کرده‌اید.

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

بازگردانی و یادداشتی که ارزش نگه‌داشتن دارد

تغییرات را به ترتیب معکوس انجامشان برگردانید. متغیرهای پروکسی را بردارید، کلاینتی را که دستی شروع کردید متوقف کنید و هر بازنویسی مسیر یا تحلیلگر را حذف کنید:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

رها کردن کلاینتی که دستی شروع شده باعث می‌شود لپ‌تاپ در بازدید بعدی از دفتر با شبکه خراب بماند. متغیرهای پروکسی که در پروفایل پوسته می‌مانند هفته‌ها بعد ابزارهای بی‌ربط را می‌شکنند و کسی که آن‌ها را اشکال‌زدایی می‌کند دو رویداد را به هم ربط نمی‌دهد.

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