VPN پیش از Tor: ترتیب واقعاً چه چیزی را تغییر می‌دهد
مسیری که با VPN آغاز می‌شود تغییر می‌دهد چه کسی نشانی مبدأ شما را می‌بیند و چه کسی ترافیک Tor را می‌بیند، و یک اعتماد دیگر اضافه می‌کند. پیش از فرض هر سودی، بررسی مسیر و خرابی را اجرا کنید.
اتصال اولیه VPN زنجیره مشخصی می‌سازد: دستگاه، نقطه پایانی VPN، ورود Tor، مدار Tor، مقصد. شبکه محلی شما یک اتصال رمزگذاری‌شده به VPN می‌بیند، و گره ورودی Tor خروجی VPN را به‌جای نشانی ارائه‌دهنده شما به‌عنوان مبدأ بی‌واسطه می‌بیند. اپراتور VPN نیز به‌نوبه خود اتصال‌هایی به زیرساخت ورود Tor می‌بیند و می‌تواند استفاده از Tor را از مقصدها استنباط کند. هر ناظر چیزی از دست می‌دهد و چیزی می‌گیرد، و به همین دلیل ترتیب یک مبادله است نه یک ارتقا.
هیچ چیز در آن زنجیره تغییر نمی‌دهد که وب‌سایت از حساب، کوکی‌ها یا جزئیات تایپ‌شده شما چه یاد می‌گیرد.
ترتیب چه چیزی را تغییر می‌دهد
شبکه محلی و ارائه‌دهنده اینترنت دید مستقیم ترافیک Tor شما را از دست می‌دهند، چون گام نخست اکنون یک تونل رمزگذاری‌شده به یک ارائه‌دهنده است. نگهبان ورود Tor نشانی خانه شما را از دست می‌دهد و خروجی VPN را می‌بیند. ارائه‌دهنده VPN فراداده‌ای را به دست می‌آورد که پیش‌تر در اختیار ارائه‌دهنده اینترنت شما بود: با کدام نشانی‌ها تماس می‌گیرید، در چه ساعت‌هایی و چه حجمی از داده جابه‌جا می‌شود.
پس از نگهبان ورود، مدار مثل قبل رفتار می‌کند. رله‌ها هنوز نقش‌های ورود، میانه و خروج را جدا می‌کنند، و VPN محتوای نهایی را بیش از ارائه‌دهنده اینترنت شما نمی‌بیند.
مسیری را که واقعاً استفاده می‌شود تأیید کنید
تونل‌سازی تفکیک‌شده دلیل معمول این است که زنجیره موردنظر همان زنجیره واقعی نیست.اگر Tor Browser از تونل مستثنا شده باشد، یا نمایه دومی متفاوت مسیریابی کند، نگهبان ورود دوباره نشانی ارائه‌دهنده را می‌بیند در حالی که رابط هنوز متصل به نظر می‌رسد. مسیر و خروجی مشاهده‌شده را بررسی کنید، نه نماد را.
ip route get 1.1.1.1 ss -tunp | grep -E 'tor|9150|9050' curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip resolvectl status | grep -A3 'DNS Servers'
درخواست SOCKS از طریق درگاه 9150 توسط کارخواه خود Tor Browser پاسخ داده می‌شود، بنابراین پاسخ IsTor true مدار مرورگر را تأیید می‌کند، نه اینکه هر برنامه دیگری از آن استفاده کند. ثبت خروجی مفسر ارزش دارد، چون DNS ممکن است از مسیری خارج شود که تونل پوشش نمی‌دهد. هر دو خروجی را با مهر زمانی نگه دارید. آن‌ها مبنای مقایسه بعدی هستند.
با یک درخواست مستقیم از ترمینال معمولی مقایسه کنید: اگر آن هم Tor را گزارش کند، چیز دیگری ترافیک را تغییر مسیر می‌دهد و زنجیره آن چیزی نیست که طراحی فرض کرده بود.
ببینید وقتی تونل قطع می‌شود چه رخ می‌دهد
کارخواهی که بی‌صدا به رابط محلی بازمی‌گردد مبدأیی را که نگهبان ورود می‌بیند تغییر می‌دهد، و کاربر معمولاً بی‌خبر است چون صفحه هنوز بارگذاری می‌شود. همین خرابی ارزش آزمودن دارد، نه مسیر بی‌دغدغه. تونل را عمداً قطع کنید و ببینید ترافیک Tor متوقف می‌شود یا بدون محافظت ادامه می‌یابد.
nft list ruleset | grep -i -E 'vpn|tun|drop' iptables -S | grep -i tun ip link show | grep -E 'tun|wg'
قواعد دیوار آتش که ترافیک خروجی بیرون تونل را مسدود می‌کنند تنها کنترل جایگزین قابل اعتمادند، و باید هم کارخواه SOCKS مرورگر و هم هر برنامه دیگری را که برایتان مهم است پوشش دهند. افزونه مرورگر یک VPN دستگاهی نیست و بر برنامه‌های دیگر یا ناظران بیرونی اثر نمی‌گذارد.
تصمیم بگیرید آیا لایه اضافه اعتمادش را به دست می‌آورد
پروژه Tor توصیه می‌کند VPN را زیر Tor نگذارید مگر اینکه خودتان بتوانید تنظیمات را ارزیابی کنید. دلیل اعلام‌شده آن‌ها وابستگی افزوده است: طرف دیگر، حساب دیگر و حالت خرابی دیگر. اگر هدف این است که ارائه‌دهنده اینترنت شما استفاده از Tor را نبیند، VPN دقیقاً همان ناظر را هدف می‌گیرد. اگر هدف ناشناس‌بودن قوی‌تر در برابر ناظر جهانی است، VPN آن را فراهم نمی‌کند.
ترتیب معکوس هم وجود دارد، و نام‌ها قابل جابه‌جایی نیستند:Tor روی VPN و VPN روی Tor روابط اعتماد متفاوتی را توصیف می‌کنند و رفتار خرابی متفاوتی. پیش از آمیختن آن‌ها مقایسه را بخوانید.
بنویسید کدام ناظر را می‌خواهید جابه‌جا کنید، سپس تأیید کنید که مسیر واقعی با طراحی می‌خواند، سپس رفتار خرابی را تأیید کنید. اگر آن سه پاسخ حساب و پیکربندی اضافه را توجیه نمی‌کنند، تنظیمات مستند Tor Browser قطعات کمتری برای اشتباه دارد.