پروکسی SOCKS5 برای OpenVPN: تونل TCP یا پروکسی کردن برنامه‌ها؟

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

یک محدودیت طراحی را تعیین می‌کند

SOCKS5 درست است که حالت انجمن UDP را مشخص می‌کند. با این حال پشتیبانی پروکسی کلاینت OpenVPN حول جریان‌ها ساخته شده است: socks-proxy برای پروفایل‌های TCP مستند شده است، و پروکسی HTTP CONNECT هیچ مسیری برای دیتاگرام ندارد. یک خط مستندات معماری را روشن می‌کند، پیش از آنکه به فایل پیکربندی دست بزنید.

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

گزینه الف: تونل را به جریان تبدیل کنید

این به سروری با شنونده TCP و پروفایل کلاینتی که پروکسی را نام می‌برد نیاز دارد. هر دو بخش لازم‌اند، و سمت سرور همان چیزی است که مردم فراموش می‌کنند:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

خط آخر را با http-proxy proxy.internal 8080 جایگزین کنید وقتی پروکسی HTTP صحبت می‌کند، و اگر فایل اعتبارنامه می‌خواهد آن را اضافه کنید. پروکسی باید حاضر باشد CONNECT را به پورت VPN شما انجام دهد و سرور باید روی TCP پاسخ دهد؛ شنونده‌ای که فقط UDP است این تلاش را نادیده می‌گیرد. انتخاب 443 اقدامی عملی است، چون بسیاری از شبکه‌های محدودکننده آن را و چیز کمی دیگر را مجاز می‌دانند.

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

گزینه ب: تونل را به حال خود بگذارید

وقتی تونل باید روی UDP بماند، تونل جایی نیست که چیزی را پیکربندی کنید. در عوض، TCP خروجی از برنامه‌ها به شنونده محلی SOCKS هدایت می‌شود، و برنامه‌ها هرگز نمی‌فهمند که پروکسی وجود دارد. در لینوکس این معمولاً redsocks به‌علاوهٔ یک قاعدهٔ NAT REDIRECT در جدول nat است.

دوباره فقط TCP. پروکسی فقط HTTP مثل privoxy نمی‌تواند پروتکل‌های دلخواه را عبور دهد، و این طراحی هیچ پشتیبانی دیتاگرامی هم برای برنامه‌ها اضافه نمی‌کند.

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

هر گزینه کجا شکست می‌خورد

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

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

هیچ‌کدام از گزینه‌ها نیاز دستگاه را تغییر نمی‌دهد. بسته‌ها هنوز پیش از مسیریابی کرنل به گره TUN یا TAP نیاز دارند، پس فرایند هنوز به اجازه روی /dev/net/tun. یک پوشش تغییر می‌دهد که پس از باز شدن آن گره چه رخ می‌دهد، نه اینکه به آن نیاز دارید یا نه.

اثبات اینکه کدام مسیر را ساخته‌اید

به سوکت‌ها نگاه کنید نه به آیکون سینی. فرایند VPN باید اتصال برقرارشده به آدرس پروکسی را نگه دارد، و پروکسی باید هدفی را که خواسته شد به آن برسد ثبت کرده باشد:

ss -tnp | grep openvpn

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

انتقال و پروکسی پذیرنده را در جایی پایدار یادداشت کنید. وقتی همان پروفایل در شبکهٔ دیگری شکست می‌خورد، آن یادداشت در چند ثانیه پروکسی را کنار می‌گذارد یا تأیید می‌کند.