Å opne ein ny nettlesar lagar ikkje ei ny VPN-rute
Profilar og private vindauge skil nettlesaren sin tilstand, ikkje nettverksbaner. Ei ny rute krev ein regel per app, ein proxy eller eit namnerom, og kvar av dei har sin pris.
To nettlesarar, to vindauge, det eine på jobbkontoen og det andre på ein personleg konto, og føresetnaden er at dei no følgjer ulike baner. Det gjer dei ikkje. Profilskilje held informasjonskapslar frå kvarandre, medan avgjerda om ruta blir teken under nettlesaren og veit ikkje kva profil som spurde. Ei ny bane krev ein regel som vel denne, og det er berre nokre få stader ein slik regel kan bu.
Tilstandsskilje er ikkje baneskilje
Ein nettlesarprofil isolerer lagring: informasjonskapslar, historikk, utvidingar og nokre gonger påloggingsdetaljar. Det isolatet blir handheva inne i eitt prosesstre og har ingenting å seie om kva grensesnitt som ber ein pakke.
Private vindauge går lenger i utsjånad og ikkje eitt steg lenger i ruting. Alt nettlesaren sender forlèt framleis bana operativsystemet har valt, med mindre noko mellom sokkelen og nettverket endrar henne. Å blande lagringsisolat med nettverksisolat skapar forventingar som ingen nettlesarprodusent har lova og ingen test kan innfri.
Kva som faktisk vel ei rute
Fire ting kan velje ei anna bane: ein VPN-regel per app som samsvarar med den køyrbare fila eller pakken, ein proxy konfigurert inne i nettlesaren eller systemet, eit nettverksnamnerom eller ein container, og ei anna fysisk eining. Kvar av dei endrar noko verkeleg, og kvar har sin pris.
Ein regel per app er det vanlege svaret på mobile plattformer, der VPN-tenesta får ei pakkeliste. På ein datamaskin kjem det an på klienten, og ein regel som samsvarar med den køyrbare fila, dekkjer kvar profil som den fila opnar. Viss to profilar verkeleg treng ulike baner, treng dei vanlegvis to prosessar med ulike identitetar i staden for to faner. Difor kan ein delt nettlesarinstallasjon aldri vere grensa i eit design per profil.
Proxyar på appnivå legg til ein ny mellommann
Ei proxyinnstilling i nettlesaren lagar faktisk ei separat bane, og ho lagar òg eit separat tillitsforhold til den som driv proxyen. Det er ei legitim ordning for éin profil, og ho svarar ikkje til dekkjing av heile eininga.
Vel proxyen med vilje: ein SOCKS-lyttar på same vert, ein autentisert proxy inne i tunnelen eller ei ekstern teneste. Å blande ein proxy med ein VPN med full tunnel gjev nesta baner der feilmodusane multipliserer seg.
Kontroller den faktiske førespurnaden til kvar nettlesar
Send den same førespurnaden frå kvar nettlesar og samanlikn den observerte utgangsadressa, i staden for å samanlikne innstillingssidene. Ein konfigurert proxy som lydlaust ikkje får kopla til, er ein svært vanleg måte å hamne tilbake på standardbana.
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
Gjenta deretter førespurnaden med proxyen tvinga og med tunnelen nede, for å sjå kva lag som faktisk ber trafikken. Noter òg DNS-svaret, fordi ein nettlesar med sin eigen krypterte resolver kan gå heilt utanom systembana og likevel vise sida du venta.
Skriv ned den tiltenkte tilordninga på to linjer: kva prosess som brukar kva bane, og kven som eig kvar av dei. Ha òg kontoidentitetane i syne, fordi to baner ikkje hindrar at same pålogging blir lagd fram for båe måla. Test på nytt etter neste nettlesaroppdatering, fordi ei proxyinnstilling lett går tapt og er vanskeleg å leggje merke til.