UDP از طریق درگاه SOCKS تور: چه چیزی منتقل نمی‌شود

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

بررسی کنید برنامه واقعاً چه می‌فرستد

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

درگاه مقصد و ناقل را برای بخشی که شکست می‌خورد بنویسید. همان یک خط تعیین می‌کند که آیا واسط اصلاً می‌تواند کمکی کند.

رابط SOCKS تور چه چیزی را می‌پذیرد

تور فرمان SOCKS5 CONNECT را برای اتصال‌های جریانی و فرمان‌های افزونه را برای حل نام پیاده‌سازی می‌کند، و به همین دلیل مرورگر بدون تغییر از آن کار می‌کند. UDP ASSOCIATE، فرمانی که به کاربر اجازه می‌داد بسته‌های داده را برای بازپخش به واسط بسپارد، بخشی از آنچه تور عرضه می‌کند نیست. مستندات افزونه‌ها در مشخصات افزونه‌های SOCKS پروژه است و کوتاه است. نبود فرمان بسته‌های داده عمدی است: بازپخش UDP خودسرانه به شبکه نقشی می‌داد که هرگز برای آن طراحی نشده بود.

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

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

بررسی را به ترتیب اجرا کنید

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

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

بازگردانید و ابزار درست را انتخاب کنید

هر متغیر محیطی واسط یا تنظیم واسط هر برنامه را که کاربر UDP را به درگاه SOCKS می‌برد حذف کنید؛ باقی گذاشتن آنها آزمون‌های بعدی را مبهم می‌کند. پیکربندی پیشین را از یک نسخه بازگردانید، برنامه را دوباره راه‌اندازی کنید و تأیید کنید که رفتار اصلی بازمی‌گردد تا مقایسه پاک باشد. بازگردانی‌ای که تأیید نشود تنها امیدی است به اینکه وضعیت تغییر کرده است.

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