Що локальна мережа досі бачить через ваш VPN
Тунель приховує вміст, а не вашу присутність. Порівняйте, що дізнаються мережа доступу, керований пристрій і оператор VPN, перш ніж вважати, що одне закриває все.
Троє спостерігачів зливаються в одне питання щоразу, коли хтось питає, чи приховує VPN його трафік: мережа, до якої він під’єднаний, машина в його руках і оператор тунелю. Кожен дізнається щось інше, і тунель змінює кожен із цих поглядів по-різному. Корисно працювати у зворотному напрямку й починати з твердження, бо саме твердження має витримати перевірку. Вирішіть, яке твердження вам потрібне, і порівняйте з ним інструменти.
Перше твердження: ніхто не може прочитати трафік
Почніть із найвужчого твердження: корисне навантаження залишається нечитабельним. Пасивний спостерігач на шляху не бачить усередину сеансу TLS, тож тунель мало що додає сайту, який уже використовує HTTPS, і нічого не додає проти двох кінцевих точок. Це твердження ламає той, хто контролює пристрій, бо проксі перевірки завершує з’єднання й підписує його заново коренем, якому машина вже довіряє. Тому замок досі з’являється, поки ланцюг сертифікатів несе ім’я організації, яка встановила корінь.
security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root
У macOS цей конвеєр виводить по одному рядку суб’єкта для кожного сертифіката у зв’язці ключів машини, не відкриваючи вікна, а у Windows certutil -store Root перелічує те саме сховище, яке certlm.msc показує графічно. Корінь, що належить школі, роботодавцю або продукту мережевої безпеки, це запис, який варто шукати. Знайти один доводить лише те, що перехоплення можливе, а не те, що воно відбувається.
Що ви можете з цим зробити, це питання політики, а не техніки. Видалення профілю або кореня перевірки з обладнання, яке вам не належить, зазвичай порушує угоду про прийнятне використання, а система керування зазвичай це помічає і застосовує знову, тож вимога, щоб власник пристрою не читав ваш трафік, потребує іншого пристрою, а не іншого налаштування.
Друге твердження: ніхто не бачить, куди ви йдете
Призначення це складніше твердження, бо два розкриття відбуваються до завантаження сторінки. Запит іде до того резолвера, який налаштований у системі, і відповідь видима мережі, що її несе. Далі рукостискання TLS передає запитане ім’я сервера відкрито, якщо Encrypted Client Hello не підтримується на обох кінцях. Жодне з розкриттів не потребує розшифрування, тож тунель не впливає на жодне з них.
resolvectl status | grep -A2 "Link"
nslookup example.com
Який резолвер насправді використовується, те й визначає вразливість, і це можна виміряти, а не обговорювати. У Linux resolvectl status виводить DNS-сервери для кожного з’єднання, і його вивід каже, чи відповідає резолвер сайту, чи нав’язаний. Windows відповідає на те саме питання за допомогою nslookup example.com, перший блок виводу якого це DNS-сервер, що відповів.
Коли ноутбук звертається до резолвера сайту до підняття тунелю, або профіль надходить без замінного сервера, тож старий залишається в роботі, адміністратор усе одно збирає імена хостів, нічого не розшифровуючи. Зашифрований DNS у браузері або обходить нав’язаний резолвер, або блокується повністю й відмовляє закрито. Оператор виходу бачить ті самі імена зі свого боку. Тому зміна резолвера не відводить це розкриття від провайдера тунелю.
Третє твердження: ніхто не знає, що ви під’єдналися
Третє твердження це те, яке тунель не може забезпечити, бо пакети все ще перетинають локальну мережу. Ця мережа дізнається адресу кінцевої точки, приблизний обсяг, час і існування одного довготривалого зашифрованого сеансу, чого достатньо, щоб блокувати, обмежувати або просто помічати. Міжмережевий екран, який не може прочитати пакет, усе одно може відмовитися його пропустити. Бути під наглядом це не те саме, що не бути під наглядом нікого: ви перемістили спостерігача, а не видалили його.
Розділене тунелювання і будь-який застосунок, що ігнорує нав’язаний маршрут, створюють потоки поза тунелем, які виглядають точно як раніше. Саме їх уважний спостерігач помічає першими, а таблиця маршрутів клієнта показує, які призначення виключено.
Оператор на іншому кінці має дзеркальне відображення цього погляду: адреса виходу, час, обсяг і зазвичай назви сайтів. Ваш провайдер стає стороною з точкою огляду, а це інша угода, ніж невидимість. Вибрати провайдера, якому довіряєте, це реальне рішення; назвати результат ненаблюдаваним ні.
Вирішіть, яке твердження вам потрібне
Запишіть вимогу одним рядком, перш ніж торкатися клієнта: приховати вміст, приховати призначення або приховати сам факт під’єднання. Вмістом уже опікуються HTTPS разом із тунелем, а призначенням потрібні резолвер і шлях, що повністю обходять обладнання сайту.
Третя вимога це незручна, бо щось усе ще видимо під’єднане десь, зашифроване чи ні. Жодне налаштування клієнта цього не змінює. Якщо вимога й політика розходяться, ця прогалина належить розмові з власником політики, а не опції в клієнті. Відповісти на це може той, хто написав політику.