Два браузъра, два прозореца, единият на служебния профил и другият на личен, и предположението е, че сега те поемат по различни пътища. Не е така. Разделянето на профили държи бисквитките отделно, докато решението за маршрут се взема под браузъра и не знае кой профил е попитал. Вторият път изисква правило, което да го избере, а местата, където такова правило може да живее, са само няколко.

Разделянето на състояние не е разделяне на път

Профилът на браузъра изолира хранилището: бисквитки, история, разширения и понякога идентификационни данни. Тази изолация се налага в едно дърво от процеси и няма думата за това кой интерфейс носи пакета.

Поверителните прозорци отиват по-далеч във вида и нито крачка по-далеч в маршрутизацията. Всичко, което браузърът изпраща, все още излиза по избрания от операционната система път, освен ако нещо между сокета и мрежата не го промени. Объркването на изолацията на хранилището с изолация на мрежата поражда очаквания, които никой производител на браузъри не е обещавал и които никой тест не може да задоволи.

Какво всъщност избира маршрут

Четири неща могат да изберат друг път: правило за 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, защото браузър със собствен шифрован резолвер може напълно да заобиколи системния път и пак да покаже страницата, която сте очаквали.

Запишете предвиденото съответствие в два реда: кой процес използва кой път и кой притежава всеки от тях. Дръжте под око и идентичностите на профилите, защото два пътя не пречат един и същ вход да бъде представен на двете дестинации. Тествайте отново след следващото обновяване на браузъра, защото настройката на прокси лесно се губи и трудно се забелязва.

Подобни статии