مسیریابی سیاستی در برابر SOCKS: کدام لایه واقعاً ترافیک را پروکسی می‌کند

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

مسیریابی، DNAT و SOCKS چیزهای متفاوتی را تغییر می‌دهند

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

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

پس از آن، هسته بسته را به 10.50.0.2 تحویل می‌دهد و مقصد اصلی هنوز در سرآیند IP است. اگر 10.50.0.2 یک مسیریاب باشد، بسته را ارسال می‌کند. اگر میزبانی با دیمن SOCKS روی 1080 باشد، بسته به چیزی که بتواند آن را بپذیرد نشانه‌گذاری نشده است، و DNAT به پورت 1080 هم کمکی نمی‌کند، زیرا بسته ترجمه‌شده هنوز بار مفید اصلی برنامه را به جای سلام SOCKS حمل می‌کند.

SOCKS5 با یک بایت نسخه، فهرست روش‌ها، تبادل احراز هویت و درخواستی که مقصد را نام می‌برد آغاز می‌شود. این‌ها داده برنامه‌اند. هیچ ورودی مسیریابی و هیچ هدف netfilter آن را تولید نمی‌کند، و این مقایسه در یک خط است: مسیریابی مسیر را انتخاب می‌کند، SOCKS از سرور می‌خواهد اتصال دومی بسازد.

حالت یک: برنامه خودش می‌تواند SOCKS صحبت کند

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

برنامه‌هایی که متغیرهای محیطی پروکسی را نادیده می‌گیرند یا سوکت خام باز می‌کنند، به این روش کمکی نمی‌گیرند. مرورگرها و بیشتر ابزارهای HTTP خوب هستند؛ یک کلاینت بازی، یک دیمن ایمیل یا یک فایل دودویی دلخواه فروشنده معمولاً نیست. مرز برای هر برنامه و هر پروتکل است، از این رو این گزینه برای آزمایش عالی و به عنوان پاسخ برای کل VPN ضعیف است.

حالت دو: مبدلی که جریان‌های IP را به نشست‌های پروکسی تبدیل می‌کند

برای برنامه‌هایی که نمی‌توانند SOCKS صحبت کنند، تبدیل باید در چیزی رخ دهد که ترافیک IP را پایان می‌دهد و به نام آن‌ها نشست پروکسی باز می‌کند. آن مؤلفه یک رابط تونل دارد، جریان‌هایی را که مسیریابی سیاستی انتخاب کرده می‌پذیرد، برای هر یک مصافحه SOCKS انجام می‌دهد و پاسخ‌ها را بازمی‌سازد. مسیر ترافیک را به آن می‌فرستد؛ مبدل همان چیزی است که نشست را می‌سازد.

پیش از آن‌که یک زیرشبکه کامل را به آن بسپارید مستنداتش را بخوانید. بسیاری از مبدل‌ها TCP را خوب حمل می‌کنند و UDP را فقط از طریق انجمن UDP در SOCKS5 مدیریت می‌کنند، و هیچ‌کدام ICMP را به ترافیک پروکسی تبدیل نمی‌کند، پس یک ping موفق درباره مسیر پروکسی چیزی نمی‌گوید. DNS تله دیگر است: اگر مبدل نام‌ها را محلی حل کند، رکوردهای فقط داخلی به پاسخ غلط یا به هیچ چیز حل می‌شوند.

جلوگیری از حلقه همان جزئیات عملیاتی است که گاز می‌گیرد. اتصال‌های خود مبدل به سرور SOCKS نباید دوباره به مبدل مسیریابی شوند، پس ترافیکش به یک استثنا در قاعده یا یک نشانی مبدأ اختصاصی نیاز دارد. اگر این را اشتباه کنید، نشست پروکسی می‌کوشد خودش را پروکسی کند.

حالت سه: میزبان در واقع یک دروازه مسیریابی‌شده است

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

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

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

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

لایه را با چهار پرسش انتخاب کنید

آیا برنامه تنظیم پروکسی دارد؟ از آن استفاده کنید و همان‌جا بایستید. آیا ترافیک شامل UDP یا ICMP است که باید زنده بماند؟ فقط یک دروازه مسیریابی‌شده یا دروازه NAT، ICMP را حمل می‌کند، و UDP به انجمن SOCKS5 نیاز دارد که هر دو طرف پشتیبانی کنند. آیا باید هر فرایند روی دستگاه پوشش داده شود، از جمله آن‌هایی که نمی‌توانید پیکربندی کنید؟ پس به مبدلی نیاز دارید که رابط را در اختیار دارد و جریان‌ها را پایان می‌دهد. آیا می‌توانید مسیریابی، DNS و استثناهای جلوگیری از حلقه آن را هم بر عهده بگیرید؟ اگر نه، دروازه ساده هزینه کمتری برای بهره‌برداری خواهد داشت.

یک تمایز ارزش نگه‌داشتن دارد. گزینه socks-proxy خود یک کلاینت VPN توصیف می‌کند که اتصال تونل بیرونی چگونه به سرور خود می‌رسد، و درباره تبدیل جریان‌های داخلی کلاینت چیزی نمی‌گوید. این دو در همان تیکت مدام با هم اشتباه می‌شوند. پیش از دست زدن به یک مسیر تصمیم بگیرید به کدام رابطه نیاز دارید.