آیا اپراتور VPN می‌تواند ببیند کدام سایت‌ها را بازدید می‌کنید؟
سرور OpenVPN پیش‌فرض نشست‌ها را ثبت می‌کند، نه URLها. پیش از ادعا درباره آنچه اپراتور می‌بیند، گزارش‌های اتصال، ضبط تونل و آزمون نشت DNS را مقایسه کنید.
بپرسید VPN چه می‌بیند، و پاسخ بستگی دارد به جایی که در مسیر ایستاده‌اید. در لایه نشست، اپراتور رویدادهای احراز هویت و شمار بایت‌ها را دارد. در لایه بسته، آدرس‌های مقصد و زمان‌بندی. در لایه DNS ممکن است خود نام‌ها را داشته باشد. هر لایه به پرسشی دیگر پاسخ می‌دهد و هیچ کلید واحدی شما را میان آن‌ها جابه‌جا نمی‌کند.
پیش از ادعا، لایه را نقشه‌برداری کنید
همان اتصال در هر نقطه رکوردهای متفاوتی تولید می‌کند و سخنی درباره حریم خصوصی تنها وقتی معنا دارد که نقطه را نام ببرد. جدول را ستون‌به‌ستون بخوانید: چه چیزی در آن لایه وجود دارد، اپراتور آنجا چه می‌بیند و همان رکوردها چه چیزی را هنوز نمی‌توانند به او بگویند.
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
خواندن یک لایه به‌عنوان تمام تصویر، آغاز هم گزافه‌گویی‌ها و هم آرامش کاذب است. ارائه‌دهنده‌ای که می‌گوید مرور را ثبت نمی‌کند می‌تواند درباره ثبت URL درست باشد و در همان حال رکوردهای نشست را نگه دارد؛ و ضبط بسته‌ای که تنها آدرس‌ها را نشان می‌دهد بدون جست‌وجوی معکوس و حدس، تاریخ مرور نمی‌شود.
هنگام ارزیابی یک سیاست، جمله‌ای را بیابید که هر لایه را توصیف می‌کند. اگر سیاست آن‌ها را جدا نمی‌کند، به‌جای پذیرش سخنی کلی درباره رمزنگاری، بپرسید چه رکوردهایی وجود دارد.
فهرست نشست‌ها: سرور OpenVPN استاندارد چه چیزی نگه می‌دارد
به‌طور پیش‌فرض، سرور OpenVPN ترافیک را ضبط نمی‌کند. خروجی معمول یک فهرست نشست است: حسابی که احراز هویت کرده، آدرس مبدأیی که از آن آمده، برچسب‌های زمانی آغاز و پایان، آدرس تونل تخصیص‌یافته و مجموع بایت‌ها در هر جهت. این فهرست نشست‌هاست، نه فهرستی از مقصدها.
گزینه‌های ثبت می‌توانند جزئیات بیفزایند. سطح پرگویی بالاتر بیشتر درباره دست‌دادن می‌نویسد و فایل وضعیت می‌تواند کلاینت‌های متصل را فهرست کند، اما هیچ‌کدام سرور را به پروکسی شفاف تبدیل نمی‌کند. تولید URL به پایان‌دادن TLS یا اجرای پروکسی صریح نیاز دارد و هر دو ترتیب اعتماد را تغییر می‌دهند، نه اینکه ویژگی پنهانی را فعال کنند.
به همین دلیل نسخه دقیق ادعای نبود گزارش مرور از آنچه به نظر می‌رسد محدودتر است. سرور صفحه را نمی‌داند، اما می‌داند نشستی وجود داشته و تقریباً چه حجمی از داده از آن گذشته است. اینکه آن رکورد نشست نگه داشته شود و چه مدت، پرسشی جداگانه در سیاست است.
بسته‌های درونی و بیرونی شواهد متفاوتی‌اند
ضبط بسته راهی است برای دیدن آنچه واقعاً از تونل می‌گذرد. روی سرور، رابط تونل را نام ببرید و در فایلی بنویسید که بتوان بیرون از شبکه تحلیلش کرد:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headآن فایل ترافیک درونی رمزگشایی‌شده را دارد: آدرس تونل کلاینت به‌عنوان مبدأ، آدرس و درگاه مقصد، اندازه بسته‌ها و زمان‌بندی. مسیر HTTP یا بدنه پاسخ را ندارد مگر آنکه TLS جایی پایان یافته باشد، و داده‌ای حساس است که نگهداری‌اش تصمیم سیاست است نه آسودگی اشکال‌زدایی.
ضبط روی رابط فیزیکی چیز دیگری نشان می‌دهد. آنجا بسته‌های بیرونی خطاب به نقطه پایانی VPN را می‌بینید با بار رمزشده در درون. آدرس‌های نامرتبط در آن فایل طبیعی‌اند وقتی آداپتور مجازی وجود دارد، زیرا دستگاه تونل جریان‌های درونی را حمل می‌کند و انتقال رمزشده جریان‌های بیرونی را.
بپرسید ضبط باید به چه پرسشی پاسخ دهد. استفاده یک برنامه از تونل روی آداپتور مجازی دیده می‌شود؛ دسترسی تونل به نقطه پایانی روی رابط فیزیکی. به‌کارگیری هر یک از این فایل‌ها به‌عنوان تصویر کامل، نتیجه‌هایی می‌دهد که داده‌ها پشتیبانش نیستند.
DNS جایی است که نام‌ها دیده می‌شوند
DNS استثنای عملی می‌ماند. resolver نام‌هایی را که برای حل‌کردن خواسته شده می‌بیند، پس هر که آن را اداره می‌کند می‌فهمد کلاینت کدام سایت‌ها را جست‌وجو می‌کند، حتی وقتی اتصال‌های بعدی رمزشده‌اند. ضبط تونل آدرس‌ها را نشان می‌دهد؛ resolver نام‌ها را.
بررسی کنید resolver برای رسیدن به سرویس بیرونی از کدام آدرس استفاده کرده. پاسخ، آدرس خروجی resolver است و مقایسه آن با خروجی VPN به شما می‌گوید پرس‌وجو از تونل گذشته یا نه:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53اگر آن آدرس با اتصال محلی همخوان باشد نه با خروجی تونل، جست‌وجو VPN را دور زده و نام روی مسیر محلی دیده می‌شده است. پس از به‌روزرسانی کلاینت بررسی را تکرار کنید، زیرا نسخه تازه می‌تواند تغییر دهد پروفایل کدام resolver را نصب می‌کند.
DNS رمزشده دیده‌شدن را جابه‌جا می‌کند نه حذف. شبکه دیگر پرس‌وجو را نمی‌بیند، اما resolver همچنان می‌بیند و پرسش اعتماد تنها دست‌به‌دست می‌شود. نام سرور TLS در دست‌دادن اتصال نشانه‌ای جزئی دیگر است: اغلب حتی وقتی بار مبهم است زنده می‌ماند، پس آدرس‌های مقصد تنها فراداده‌ای نیستند که سرور ارسال‌کننده می‌تواند ببیند.
سه گونه رکورد و چه کسی می‌تواند بخواندشان
حسابداری نشست، رکوردهای هر نام و شواهد نشت سه محصول متفاوت با سه تعهد متفاوت‌اند. گزارش‌های نشست ارزان و کم‌حساسیت‌اند و پاسخ می‌دهند چه کسی کِی وصل شد. رکوردهای هر نام به resolver ثبت‌کننده یا پروکسی صریح نیاز دارند و تعهدی برای افشا در برابر افراد آسیب‌دیده می‌سازند. شاهد نشت آزمونی در سمت کلاینت است که آنچه resolver آشکار می‌کند را با خروجی تونل مقایسه می‌کند.
ثبت کنید کدام‌یک از این سه را اجرا می‌کنید، چه کسی می‌تواند بخواند و چه مدت می‌ماند. ادعاهایی که سرویس هیچ گزارشی نگه نمی‌دارد یک لایه را توصیف می‌کنند و تنها در همان دامنه درست می‌مانند. همان ارائه‌دهنده می‌تواند درباره نشست‌ها درست و درباره DNS نادرست باشد.
آزمون را تکرارپذیر نگه دارید: همان پرس‌وجوی resolver، همان رابط ضبط و همان مقایسه. ادعای حریم خصوصی که در لایه‌ای نام‌برده آزمودنی نیست، شعار است نه واقعیت عملیاتی.