Tor آماده پیش از VPN: ترتیب درست دروازه راه‌اندازی

تماشای یک فرآیند tor و سپس راه‌اندازی VPN رایج‌ترین راه برای ساختن اشتباه این پشته است. دیمن خیلی پیش از آنکه بتواند جریان یک کلاینت را حمل کند ظاهر می‌شود، و یک مکث ثابت حدسی است که لباس وابستگی پوشیده است. دروازه باید همان حالتی باشد که مؤلفه بعدی واقعاً به آن نیاز دارد. چهار مرحله زیر را به ترتیب طی کنید و هر یک را شرطی جداگانه بدانید، نه تأخیری برای تنظیم.

مرحله 1: انتقالی را انتخاب کنید که واقعاً دارید

با پروتکل شروع کنید، چون بقیه طراحی به آن وابسته است. رابط SOCKS در Tor دستور UDP ASSOCIATE را پیاده‌سازی نمی‌کند، بنابراین هر چیزی که از آن عبور کند باید جریان TCP باشد. پروفایل OpenVPN که از UDP استفاده می‌کند از این مسیر کار نخواهد کرد، هر طور که سوپروایزر نوشته شده باشد. پروفایل را به TCP تغییر دهید و پیش از دست زدن به منطق راه‌اندازی تأیید کنید که همتای دور آن را می‌پذیرد.

سپس تأیید کنید که کلاینت شما اصلاً به یک پروکسی SOCKS می‌رسد. OpenVPN 2.6 گزینه‌ای به نام socks-proxy برای پروفایل‌های TCP مستند می‌کند، و کلاینت‌های مختلف پشتیبانی پروکسی متفاوتی ارائه می‌دهند. راه‌اندازی که گزینه پروکسی را بی‌صدا نادیده می‌گیرد مستقیماً وصل می‌شود و به نظر می‌رسد کار می‌کند، که از شکست بدتر است.

انتقال انتخاب‌شده را در ران‌بوک بنویسید، چون هر بررسی بعدی به آن وابسته است.

مرحله 2: فاز bootstrap را بخوانید، نه فهرست فرآیندها

پروتکل کنترل Tor به GETINFO status/bootstrap-phase با جدیدترین وضعیت bootstrap پاسخ می‌دهد، شامل درصد پیشرفت و یک برچسب خلاصه. آن پاسخ دقیقاً از این رو سودمند است که یک کنترل‌کننده می‌تواند پس از پایان bootstrap دیمن متصل شود. سوپروایزری که تنها به رویدادها گوش می‌دهد حالتی را از دست می‌دهد که Tor پیش از شروع سوپروایزر آماده بوده است.

اتصال کنترل را درست احراز هویت کنید. درگاه کنترل یک رابط مدیریتی است و هر کس بتواند با آن حرف بزند می‌تواند دیمن را دوباره پیکربندی کند. آن را روی localhost نگه دارید، احراز هویت با کوکی یا گذرواژه را فعال بگذارید و برای ساده‌تر کردن اسکریپت راه‌اندازی هیچ‌کدام را حذف نکنید.

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

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

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

مرحله 3: منتظر رویداد مدار کلاینت بمانید

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

رویداد را اجازه تلاش بدانید، نه تضمینی درباره هیچ مقصد مشخصی. سیاست خروج می‌تواند همتای دور را همچنان رد کند و دست‌دادن خود VPN می‌تواند همچنان به دلایلی شکست بخورد که هیچ ارتباطی با Tor ندارد.

دو شرط را در کد جدا نگه دارید. یک مقدار بولی به نام ready آن‌ها را یکی می‌کند و رویداد بعدی را ناخوانا می‌سازد.

مرحله 4: VPN را به دست‌دادن خودش مشروط کنید

VPN شرط آمادگی خودش را دارد و تنها همان است که اثبات می‌کند تونل بالا آمده است. صبر کنید تا کلاینت وضعیت متصل با نشانی تخصیص‌یافته را گزارش کند، سپس بررسی کنید که الزام پروکسی به قوت خود مانده است. حلقه‌ای که پس از یک شکست گزینه socks-proxy را رها می‌کند مستقیماً وصل می‌شود و بی‌صدا تمام طراحی را نقش بر آب می‌کند.

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

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

چهار گذاری را که باید از سر بگذرانید بررسی کنید

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

آن‌ها را آگاهانه، یکی یکی اجرا کنید و تغییرهای حالت را بخوانید نه فهرست فرآیندها را.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

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