Чи може оператор VPN бачити, які сайти ви відвідуєте?

Запитайте, що може бачити VPN, і відповідь залежить від того, де ви стоїте на шляху. На рівні сесії оператор має події автентифікації та лічильники байтів. На рівні пакетів має адреси призначення й час. На рівні DNS може мати самі назви. Кожен рівень відповідає на інше питання, і жоден перемикач не переносить вас між ними.

Визначте рівень, перш ніж щось твердити

Те саме з'єднання створює різні записи в кожній точці, і твердження про приватність має сенс лише тоді, коли називає цю точку. Читайте таблицю стовпець за стовпцем: що існує на цьому рівні, що оператор може там побачити і чого ті самі записи все ще не можуть сказати.

Читання одного рівня як повної картини — початок і перебільшених обіцянок, і хибного спокою. Постачальник, який каже, що не веде журнал перегляду, може бути точним щодо журналювання 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 залишається практичним винятком. Розв'язувач бачить назви, які його просять розв'язати, тому той, хто ним керує, дізнається, які сайти шукає клієнт, навіть коли подальші з'єднання зашифровані. Запис тунелю показує адреси; розв'язувач показує назви.

Перевірте, якою адресою розв'язувач дістався зовнішнього сервісу. Відповідь — це вихідна адреса розв'язувача, і порівняння з виходом VPN каже, чи запит пройшов через тунель:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Якщо ця адреса збігається з локальним з'єднанням, а не з виходом тунелю, пошук обійшов VPN і назва була видимою на локальному шляху. Повторіть перевірку після оновлення клієнта, бо нова версія може змінити, який розв'язувач встановлює профіль.

Зашифрований DNS переміщує видимість, а не прибирає її. Мережа більше не бачить запиту, але розв'язувач бачить, і питання довіри просто змінює руки. Назва TLS-сервера в рукостисканні з'єднання — ще один частковий сигнал: вона часто зберігається навіть тоді, коли вміст непрозорий, тому адреси призначення не єдині метадані, які може спостерігати сервер пересилання.

Три типи записів і хто може їх читати

Облік сесій, записи за назвами й докази витоку — три різні продукти з трьома різними обов'язками. Журнали сесій дешеві й малочутливі, вони відповідають, хто і коли підключився. Записи за назвами потребують журналюючого розв'язувача або явного проксі й створюють обов'язок розкриття перед постраждалими людьми. Доказ витоку — перевірка на боці клієнта, що порівнює те, що розкриває розв'язувач, із виходом тунелю.

Запишіть, що з цих трьох ви ведете, хто може це читати і скільки це зберігається. Твердження, що сервіс не веде журналів, описують один рівень і залишаються правдивими лише в цих межах. Той самий постачальник може бути точним щодо сесій і помилятися щодо DNS.

Тримайте перевірку відтворюваною: той самий запит до розв'язувача, той самий інтерфейс запису і те саме порівняння. Твердження про приватність, яке не можна перевірити на названому рівні, — це гасло, а не операційний факт.