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

با ترتیب شروع کنید، نه با محصول

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

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

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

رله ورودی Tor چه می‌بیند

ورودی، یا محافظ، یک اتصال TCP معمولی روی درگاه رله می‌پذیرد و دست‌دهی TLS را با کلاینت آغاز می‌کند. در چیدمان Tor روی VPN، منبع آن اتصال خروجی VPN شماست. در چیدمان Tor-اول، نشانی‌ای است که دستگاه شما برای رسیدن به شبکه Tor استفاده کرده، معمولاً اتصال خانگی شما.

این نیمهٔ IP پرسش را پاسخ می‌دهد، اما فقط اگر تونل واقعاً اتصال را حمل کرده باشد. فرایند Tor با سوکت خودش به محافظ می‌رسد و آن سوکت تابع تنظیمات پروکسی Tor Browser نیست. مرورگر از طریق SOCKS روی 9150 با فرایند tor همراه صحبت می‌کند و سپس tor اتصال خودش را با استفاده از جدول مسیریابی هسته باز می‌کند. یک خط Socks5Proxy در torrc، یا یک انتقال کلاینت، آن مسیر را تغییر می‌دهد. چیز دیگری نه.

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

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

اگر مسیر dev wg0 یا dev tun0 را نشان داد و نشانی محلی اتصال برقرارشده نشانی تونل بود، Tor داخل VPN است. اگر مسیر رابط فیزیکی شما را نام برد، بیرون است، هر چه نشانگر خود کلاینت ادعا کند.

ارائه‌دهنده VPN شما چه می‌تواند ببیند

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

آنچه نمی‌بیند بقیهٔ مدار است. رله میانی و خروجی درون Tor انتخاب می‌شوند و ارائه‌دهنده فقط حلقهٔ منتهی به محافظ را مدیریت می‌کند. محتوای صفحه درون TLS می‌ماند که در خروجی پایان می‌یابد و تجزیهٔ نام برای ترافیک Tor هم در خروجی رخ می‌دهد، پس هیچ پرس‌وجوی DNS در ارائه‌دهنده نیست که با مقصدی همبسته شود.

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

توانایی سیاست نگهداری نیست

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

هویت حساب معمولاً از نشانی خروجی مهم‌تر است. اگر با نشانی ایمیل وارد شدید یا با کارت پرداخت کردید، ارائه‌دهنده می‌تواند نشست را بدون ثبت حتی یک مقصد به شما گره بزند. چرخش IPهای خروجی هیچ کاری در این باره نمی‌کند.

پیش از اعتماد به هر یک از دو پاسخ، پوشش را بررسی کنید

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

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

ترتیبی که من بررسی می‌کنم و در نخستین شکست می‌ایستم:

  • ip route get 203.0.113.10 دستگاه تونل را برمی‌گرداند.
  • ss -tnp | grep -i tor اتصال محافظ را با نشانی محلی تونل نشان می‌دهد.
  • ip -6 route هیچ مسیر پیش‌فرضی بیرون از تونل ندارد، یا IPv6 در کلاینت خاموش است.
  • پایین آوردن VPN اتصال tor را پایان می‌دهد یا تغییر مسیر می‌دهد، نه اینکه آن را روی پیوند فیزیکی رها کند.

کدام ترتیب با آنچه از آن دفاع می‌کنید می‌سازد

هر دو ترتیب چیزی را پنهان و چیزی را آشکار می‌کنند، پس پاسخ انتخابی دربارهٔ ناظری است که برایتان مهم است.

ObserverTor over VPNVPN over Tor
Your ISP or local networkSees a VPN connection, not TorSees a Tor guard connection
Your VPN providerSees Tor use, and your home addressSees a Tor exit as the client, not your home address
Tor entry relaySees the VPN exitSees your home address
Destination websiteSees a Tor exitSees a Tor exit

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

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

اول ناظر را تعیین کنید، دوم ترتیب را انتخاب کنید و با ip route get و ss بررسی کنید نه با نشانگر کلاینت. اگر ناظر کسی است که می‌تواند خود ارائه‌دهندهٔ VPN را مجبور کند، هیچ انتخابی از ترتیب آن را درست نمی‌کند.

مقالات مرتبط