رله Tor در برابر سرور VPN: چرا جایگزین یکدیگر نیستند
پورت باز روی رله Tor نقطه پایانی VPN نیست. ابتدا بررسی کنید پورت چه چیزی را سرویس میدهد، نقش رله، دامنه شنونده SOCKS و پروفایل.
شما یک نشانی دارید، پورت پاسخ میدهد و کارخواهی آن را بدون هیچ شکایتی میپذیرد. هیچیک از اینها رله Tor را نقطه پایانی VPN نمیکند و اشتباه گران است، چون پروفایل بهراحتی وارد میشود و بعداً در دستدهی شکست میخورد. من چهار بررسی زیر را به ترتیب به کار میبرم؛ هر کدام یک شرط توقف دارد و توقف زودهنگام همان نکته اصلی است. اگر بررسی اول شکست بخورد، بقیه نمیتوانند کمکی کنند.
بررسی کنید پورت در واقع چه چیزی را سرویس میدهد
پورت باز فقط وجود یک شنونده را ثابت میکند، نه بیشتر. ORPort یک رله پس از دستدهی TLS با سلولهای خود Tor صحبت میکند، بنابراین یک کاوش موفق TLS تقریباً هیچ چیزی درباره پذیرفته شدن یک پروتکل VPN در آنجا نمیگوید:
nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null
گواهی را بخوانید، نه صرفاً وجود آن را. رلهها گواهی خودامضا با نامی عمداً غیرچشمگیر ارائه میدهند، چون ترافیک رله باید شبیه HTTPS معمولی باشد؛ گواهی سرور VPN نامی را دارد که پروفایل شما انتظار دارد. اگر طرف مقابل هرگز به اولین بسته پروتکل VPN پاسخ ندهد، هیچ مقدار ویرایش پروفایل نتیجه را تغییر نمیدهد.
اگر نشانی دستدهیای را که کارخواه شما میفرستد کامل نمیکند، اینجا توقف کنید. این پاسخ پروتکل است، نه مشکل پیکربندی، و شایعترین دلیل ماندن یک پروفایل واردشده در وضعیت 'connecting' برای همیشه همین است.
نقش رله را بررسی کنید، نه اندازه شبکه را
نقشهای رله کارهای متفاوتی انجام میدهند. نگهبان نخستین گام برای کارخواههاست، رله میانی مدارها را میان رلههای دیگر میفرستد، خروجی همان است که مقصدها را لمس میکند، و پل یک نقطه ورود غیرعمومی است که از طریق BridgeDB توزیع میشود. واژهنامه Tor این تعریفها را جدا نگه میدارد و دسترسپذیری بخشی از هر نقش است، در حالی که اجازه سرویسدادن به کارخواههای دلخواه بخشی از هیچیک نیست.
سیاست خروج ارزش خواندن دارد، چون تنها بخشی است که به یک قاعده ارسال میماند و مقصدهایی را کنترل میکند که خروج اجازه بیرون رفتن به آنها میدهد، نه کارخواههایی را که اجازه ورود دارند. سیاست خروج محدودکنندهای که پورت 25 را مسدود میکند چیزی درباره کنترل سوءاستفاده خروجی میگوید، نه درباره اینکه آیا میتوانید کارخواه OpenVPN را به این ماشین نشانه بگیرید.
اگر از شهرت استدلال میکنید، توقف کنید: چون رلهها ترافیک را میفرستند، نشانی باید نشانی شما را بپذیرد. Tor مسیرها را از طریق اجماع و پروتکل خودش انتخاب میکند؛ کارخواه VPN مشارکتکننده نیست و مداری برای پیوستن ندارد.
بررسی کنید شنونده SOCKS محلی است یا عمومی
کارخواه Tor رابط SOCKS را برای برنامههای روی همان ماشین فراهم میکند، بهطور پیشفرض روی loopback. آن شنونده یک راحتی محلی است، نه سرویسی که رله به اینترنت ارائه میدهد، و برخورد با آن بهعنوان یک پروکسی عمومی همان راهی است که مردم به اجرای رله بازی میرسند که قصدش را نداشتند:
ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org
نشانی اتصال نشانه است. SocksPort روی 127.0.0.1:9050 کار خود را میکند؛ یکی که روی 0.0.0.0 گوش میدهد و از بیرون دسترسپذیر است پروکسی باز است، و کنترلهای سیاست دسترسی خود Tor دقیقاً به این دلیل وجود دارند که این افشا یک مشکل است نه یک ویژگی.
برای برنامهای که به Tor نیاز دارد، آن را به پورت loopback نشانه بگیرید و بگذارید Tor نامها را حل کند، که شکل socks5h بالا همین کار را میکند. نشانی رله را جای آن پورت نگذارید؛ رله رابطی را که برنامه شما میخواهد ارائه نمیدهد.
بررسی کنید پروفایل VPN با یک نقطه پایانی واقعی مطابقت دارد
پروفایل VPN مجموعهای از انتظارهاست: OpenVPN به گواهی سرور یا CA، گواهی و کلید کارخواه و معمولاً یک کلید TLS نیاز دارد، در حالی که WireGuard به کلید عمومی طرف مقابل، یک نقطه پایانی و IPهای مجاز نیاز دارد. هیچیک از اینها را نمیتوان از یک نشانی و یک پورت باز استخراج کرد، به همین دلیل پروفایلی که اینگونه ساخته شود در نخستین تبادل شکست میخورد، نه هنگام اتصال.
وقتی پروفایلی به شما داده میشود، آن را در برابر نقطه پایانی که کنترل میکنید یا ارائهدهندهای که میتوانید شناسایی کنید بررسی کنید:
wg show
openvpn --config client.ovpn --verb 4
در گزارش OpenVPN، خطای مذاکره TLS مستقیماً ناسازگاری را نام میبرد؛ در wg show، طرف مقابلی که خط دستدهی ندارد هرگز یکی را کامل نکرده است. هر دو از چرخنده انتظار کارخواه گویاترند و هر دو به مواد کلید یا پروتکل اشاره میکنند، نه به Tor.
بررسی کنید واقعاً به کدام حفاظت نیاز دارید
این همان بررسی است که معماری را تعیین میکند. مرورگر Tor به شما جداسازی مدار و دفاع در برابر اثر انگشت میدهد که VPN ندارد؛ VPN نشانی را که یک مقصد میبیند تغییر میدهد و شما را نزد ارائهدهنده احراز هویت میکند. انتخاب میان این دو پرسشی از مدل تهدید است، نه پرسشی از سازگاری، و درهمآمیختن آنها پیکربندیای میسازد که خصوصی به نظر میرسد و نیست.
زنجیرهسازی ترتیب دارد. VPNی که ترافیک Tor را حمل میکند آرایشی پشتیبانیشده است، چون کارخواه Tor فقط به TCP خروجی نیاز دارد. کارخواه VPN که درون Tor تونل شود همان چیز نیست و آن چیزی نیست که کارخواه Tor پیاده میکند، پس بر پایه آن برنامهریزی نکنید.
پیش از وارد کردن هر چیزی، هر چهار مورد را تأیید کنید:
- پورت دستدهی پروتکل شما را کامل میکند، نه فقط یک اتصال TCP.
- نقش میزبان را میدانید و ارسال را بهعنوان اجازه نمیگیرید.
- شنونده SOCKSی که استفاده میکنید loopback و متعلق به شماست، نه پورت عمومی روی رله کسی دیگر.
- کلیدها یا گواهیهای پروفایل متعلق به نقطه پایانیاند که به آن وصل میشوید.