آنچه ارائه‌دهندهٔ اینترنت شما هنوز هنگام تورنت از طریق VPN می‌بیند
تونل مقصدها را پنهان می‌کند، نه خود وجود تونل را. اتصال مشتری، حل‌کننده و آنچه همتاها و ترکرهای خصوصی در هر حال می‌آموزند را بررسی کنید.
پرسش‌ها را به ترتیب مرور کنید: شبکهٔ دسترسی چه چیزی را می‌تواند ببیند، چه چیزی بدون آن از تونل بیرون می‌رود، جستجوی نام چه چیزی را افشا می‌کند، و همتاها و ترکرها در هر حال چه چیزی یاد می‌گیرند. هر پاسخ از دیگری مستقل است و VPN تنها پاسخ نخست را کامل حل می‌کند. پاسخ چهارم جایی است که بیشتر انتظارها بی‌صدا شکست می‌خورند، چون هیچ تونلی نام حساب را از میان برنمی‌دارد.
با این تصمیم شروع کنید که کدام ناظر نگرانتان می‌کند، چون پاسخ با ناظر تغییر می‌کند.
یک اتصال جای بسیاری را می‌گیرد
وقتی مشتری واقعاً درون تونل باشد، شبکهٔ دسترسی یک اتصال رمزنگاری‌شدهٔ پیوسته به یک نشانی VPN می‌بیند. حجم، زمان‌بندی و این واقعیت که VPN در حال استفاده است همچنان دیده می‌شود؛ اما نام میزبان ترکرها، نشانی همتاها و نام پرونده‌ها نه. این بهبودی واقعی است، و باریک‌تر از آنچه بازاریابی القا می‌کند. گردانندهٔ تونل در میانه می‌نشیند و بیش از شبکهٔ دسترسی می‌بیند.
بیانیهٔ نبود گزارش، سیاست نگهداری را توصیف می‌کند نه دید فنی. این‌ها ادعاهای متفاوتی هستند و تنها نخستین آن چیزی است که یک ارائه‌دهنده می‌تواند وعده دهد.
نشت از اتصال می‌آید، نه از تونل
BitTorrent جریانی از اتصال‌های کوتاه‌عمر TCP و UDP به همتاها، ترکرها، گره‌های DHT و کشف محلی می‌سازد. مشتری را به کارت شبکهٔ فیزیکی مقید کنید، یا پس از افتادن تونل آن را دوباره راه‌اندازی کنید، و ترافیک حاصل دقیقاً همان چیزی است که تونل برای پنهان‌کردنش وجود داشت. قوانین دیوار آتش کنترلی ضعیف‌تر از آنچه به نظر می‌رسند هستند: قاعده‌ای که تنها با مسیر پیش‌فرض، تنها با IPv4 یا تنها با اتصال‌های تازه مطابقت کند، مسیرها را باز می‌گذارد. مقیدکردن مشتری به واسط تونل و بررسی آن قید، الگوی نیرومندتر است.
با توقف عمدی تونل و مشاهدهٔ این‌که آیا انتقال‌ها متوقف می‌شوند آن را بررسی کنید. اگر ادامه یابند، مشتری هرگز درون نبوده است. پس از راه‌اندازی دوبارهٔ مشتری و پس از بیدارشدن لپ‌تاپ تکرار کنید، چون قیدها معمولاً همان زمان از دست می‌روند.
DNS سایت را نام می‌برد بی‌آنکه به انتقال دست بزند
اگر جستجوی نام‌ها هنوز به حل‌کنندهٔ محلی برود، خود پرس‌وجو سایت را اعلام می‌کند در حالی که انتقال رمزنگاری‌شده می‌ماند. بردن حل به درون تونل، یا رمزنگاری آن، این شکاف را می‌بندد. هیچ‌یک از این دو برای مشتری‌ای که بسته‌هایش بیرون تونل خارج می‌شوند کاری نمی‌کند. بررسی کنید کدام حل‌کننده به کار می‌رود و پرس‌وجو از کدام واسط بیرون می‌رود؛ این دو بررسی به پرسش‌های متفاوتی پاسخ می‌دهند.
نامی که از طریق تونل حل می‌شود و انتقالی که قید را رعایت می‌کند دو ویژگی جداگانه‌اند و هر یک می‌تواند تنها شکست بخورد.
انبوهه و ترکر چیزهای متفاوتی می‌بینند
تبادل نشانی بخشی از پروتکل است، پس همتاها هر چه می‌بینند ثبت می‌کنند. اتصال از خروجی خروجی را به آن‌ها می‌دهد؛ اتصال مستقیم نشانی خانه را می‌دهد. DHT و تبادل همتا آن مشاهده را بیشتر می‌گستراند، و نشست بعدی بدون تونل می‌تواند همان درگاه مشتری و نسخه را به هم پیوند دهد. ترکر ممکن است بیشتر بداند: یک کلید عبور در نشانی URL اعلام، حساب را صرف‌نظر از این‌که بسته‌ها از کدام خروجی آمده‌اند شناسایی می‌کند.
رمزنگاری بار دیگر محور دیگری را می‌پوشاند. HTTPS یک درخواست را از خروجی به بعد محافظت می‌کند؛ HTTP ساده خط درخواست را برای هر شبکه‌ای در مسیر آشکار می‌کند، و به همین دلیل یک پروتکل را می‌توان شکل داد و دیگری را نه.
به چهار پرسش با شواهد پاسخ دهید، نه با یک نماد. نماد تنها می‌گوید که تونلی وجود دارد.