VPN از طریق Tor: اول بررسی انتقال

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

بررسی‌ها را به ترتیب انجام دهید. هرکدام تعیین می‌کند که آیا شروع بعدی ارزش دارد یا نه.

واقعاً کدام ترتیب را می‌سازید

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

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

انتقال را پیش از هر چیز دیگری بررسی کنید

رابط SOCKS در Tor جریان‌های TCP را حمل می‌کند و پیوند UDP عمومی ارائه نمی‌دهد. VPNی که انتقالش UDP است نمی‌تواند آن پیشکار را مانند یک رابط شبکه معمولی بپذیرد، و هیچ تنظیمی در کارخواه تغییر نمی‌دهد که پیشکار چه چیزی را حاضر است ارسال کند. WireGuard در شکل معمولش قربانی آشکار است. نمایه OpenVPN در حالت TCP راه‌حل معمول است و هنوز باید صریحاً به آن گفت از پیشکار استفاده کند.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

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

نقشه ناظر را بازنویسی کنید

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

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

وقتی می‌شکند لایه‌های خرابی را بشمارید

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

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

اگر مدل تهدید به دفاع‌های مرورگر Tor نیاز دارد، متوقف شوید

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

خود پروژه Tor نسبت به ترکیب‌هایی هشدار می‌دهد که کاربران نمی‌توانند درست پیکربندی کنند، و این یکی برای بیشتر مردم صادق است. این طراحی عمدی برای مدل تهدید باریک است، نه میان‌بری به ترافیک ناشناس کل دستگاه.