OpenVPN از طریق پروکسی HTTP: ابتدا پاسخ CONNECT را بخوانید
پروکسی CONNECT بایت‌ها را منتقل می‌کند، بنابراین هر دو طرف به TCP نیاز دارند. پیش از سرزنش گواهی‌ها 407، 403 و 503 را بخوانید و تأیید سرور را روشن نگه دارید.
یک کلاینت VPN را به یک پروکسی HTTP شرکتی هدایت کنید، و نخستین واقعیت مفید این است که پروکسی به پروتکل VPN صحبت نمی‌کند. یک اتصال TCP معمولی به نشانی که گفته‌اید باز می‌کند و سپس کنار می‌کشد و کلاینت و سرور را رها می‌کند تا تبادل خودشان را از میان آن جریان انجام دهند. هر چیزی که کلاینت نیاز دارد، از نوع انتقال تا شنوندهٔ سرور، باید با این چیدمان بخواند. دو ناسازگاری بیشتر شکست‌ها را توضیح می‌دهد: پروفایل UDP که به پروکسی CONNECT نشانه رفته است، و پاسخ پروکسی که اشتباهاً خطای VPN پنداشته می‌شود.
پروکسی چه چیزی را حمل می‌کند و چه چیزی را نه
پروکسی فقط یک گام انتقال است. پروکسی مرورگر شما نمی‌شود، سایت‌هایی را که از طریق تونل بازدید می‌کنید ذخیره نمی‌کند، و ترافیک درونی را نمی‌بیند مگر اینکه کسی عمداً بازرسی را پیکربندی کرده باشد. تونلی که باز می‌کند به‌حکم طراحی برایش مات است.
این یعنی پروکسی نمی‌تواند سروری را که شنوندهٔ متناظر ندارد درست کند. اجازهٔ رسیدن به یک مقصد و سرویسی که روی آن مقصد گوش می‌دهد دو واقعیت جدا هستند، و تنها اولی به مدیر پروکسی تعلق دارد.
حامل باید در هر دو سر TCP باشد
پروکسی CONNECT متعارف تنها یک جریان بایت را منتقل می‌کند ، بنابراین کلاینت باید از انتقال جریانی استفاده کند. یک قطعهٔ کلاینت برای آن حالت چنین است:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128سمت سرور به شنوندهٔ واقعی TCP روی پورتی که در خط remote آمده نیاز دارد. تغییر proto udp به proto tcp-client در یک پروفایل کلاینتی می‌سازد که جریان را انتظار دارد؛ جریان را در سمت مقابل نمی‌سازد. اگر همان سرور روی آن پورت به UDP هم پاسخ دهد، آن شنوندهٔ دیگری است، نه حالت دوم همان شنونده.
جایی که نمونهٔ جداگانهٔ TCP وجود دارد، دستگاه تونل، استخر نشانی و مسیریابی آن منابع خودش هستند. کپی کردن یک پیکربندی کارآمد و تغییر واژهٔ انتقال، آن منابع را به نمونهٔ اصلی اشاره‌گر باقی می‌گذارد و اتصالی می‌سازد که احراز هویت می‌شود و سپس هیچ چیز را مسیریابی نمی‌کند.
پیش از نتیجهٔ VPN پاسخ پروکسی را بخوانید
نخستین تبادل کلاینت یک خط درخواست است که میزبان و پورت مقصد را نام می‌برد. پاسخ به آن خط به شما می‌گوید اصلاً جریان بایتی وجود دارد یا نه، و پیش از بررسی هر گواهی یا اعتبارنامه‌ای می‌رسد:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
پاسخ کلاس 200 به CONNECT یعنی جریان وجود دارد. این پاسخ چیزی دربارهٔ معتبر بودن گواهی دروازه، تطابق کلید مشترک یا اعتبار حساب کاربر نمی‌گوید. آن بررسی‌ها بعداً و درون جریان رخ می‌دهند و با پیام‌های خود کلاینت شکست می‌خورند، نه با یک خط وضعیت HTTP. در گزارش کلاینت نخستین OpenVPN رویداد پس از دست‌دادن با پروکسی را ببینید، نه آخرین خط پیش از بسته شدن پنجره را.
اعتبارنامهٔ پروکسی و اعتبارنامهٔ VPN غالباً هویت‌های متفاوتی هستند که تیم‌های متفاوت نگه می‌دارند. 407 رمز عبور بد حساب VPN نیست، و گواهی ردشده مشکل اجازهٔ پروکسی نیست.
CONNECT چه چیزی را آشکار نمی‌کند
تونل صریح CONNECT شنود نیست. پروکسی بایت‌ها را هدایت می‌کند و نشست TLS مربوط به VPN را پایان نمی‌دهد، بنابراین تأیید گواهی سرور توسط کلاینت معنادار می‌ماند و باید روشن بماند. خاموش کردن تأیید برای عبور از پروکسی، مشکلی جز مشکل شما را حل می‌کند.
چیدمان‌های جداگانه‌ای وجود دارد که در آن‌ها سازمانی عمداً TLS را پایان می‌دهد و بازرسی می‌کند. آن‌ها پیکربندی اعتماد خودشان و تصمیم سیاست خودشان را می‌خواهند، و آن چیزی نیستند که یک خط http-proxy ساده می‌طلبد.
هزینهٔ TCP درون TCP
حمل تونل روی TCP جریان بیرونی را مرتب و با ارسال دوباره نگه می‌دارد، و ترافیک درونی هم معمولاً TCP است. این دو سازوکار بازیابی هماهنگ نمی‌شوند، بنابراین یک قطعهٔ گمشده می‌تواند همه‌چیزِ شریک در آن جریان بیرونی را تا ارسال دوباره متوقف کند. این یک معاوضهٔ واقعی برای سازگاری است، نه ارتقای رایگان.
وقتی شبکه جایگزینی برایتان نمی‌گذارد از مسیر پروکسی استفاده کنید، و جایی که سیاست اجازه می‌دهد مسیر مستقیم UDP را ترجیح دهید. در هر حال پس از هر تغییر تأیید کنید که همان پروکسی، مقصد و پروفایل به مرحلهٔ بعد می‌رسند؛ مرورگری که صفحه‌ای را در آن نشانی بار می‌کند پروتکل دیگری را به کار می‌برد و چیزی دربارهٔ تونل ثابت نمی‌کند.