Відкриття другого браузера не створює другого маршруту VPN

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

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

Розділення стану не є розділенням шляху

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

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

Що насправді обирає маршрут

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

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

Проксі на рівні застосунку додають ще одного посередника

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

Обирайте проксі свідомо: слухач SOCKS на тому самому хості, автентифіковане проксі всередині тунелю або віддалений сервіс. Змішування проксі з VPN повного тунелю створює вкладені шляхи, у яких режими відмови множаться.

Перевірте реальний запит кожного браузера

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

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

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

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

Схожі статті