Hvordan holde Tor Browser-tester atskilt fra VPN-trafikk

Eksperimentet er ikke nettleseren; det er hele settet med ruter på maskinen mens nettleseren kjører. Hvis du endrer en global proxy eller en rute for å teste Tor Browser med en VPN, arver hver annen applikasjon endringen, inkludert de som synkroniserer filer og sjekker e-post i bakgrunnen. Det trygge mønsteret er å gi eksperimentet sin egen applikasjon, sin egen profil og sin egen rute, og å vite nøyaktig hvordan alt settes tilbake. En offentlig IP-side forteller deg at én utgang ble brukt; den forteller ikke hva resten av maskinen gjorde.

Sjekk 1: navngi de tre forbindelsene

Navngi dem før du rører noen innstilling. Den normale ruten er det arbeidsapplikasjonene dine bruker i dag; den eksperimentelle ruten er det du vil at Tor Browser skal bruke; den tiltenkte feilatferden er det som skal skje når et lag faller.

Skriv de tre ned på ett sted, inkludert hvilken applikasjon som hører til hvilken rute. Årsaken er ikke byråkrati: de fleste utilsiktede lekkasjer under denne typen test kommer fra en applikasjon ingen husket kjørte, ikke fra nettleseren som testes. En passordbehandler, en chatklient og en filsynkroniseringstjeneste er all bakgrunnstrafikk som tar den ruten systemet gir dem. Å navngi dem er det som gjør grensen virkelig.

Sjekk 2: hold hver innstilling hos sitt eget program

Tor Browsers støttede konfigurasjon er ikke det samme som en systemproxyinnstilling, og den er bevisst ikke utformet for å pekes mot en vilkårlig proxy fra miljøet.

En miljøvariabel eller en nettleserutvidelse kan lage en tredje rute som verken nettleserdokumentasjonen eller notatene dine beskriver. Foretrekk den støttede innstillingen inne i applikasjonen framfor en global overstyring.

Det samme gjelder alt nettleseren gir videre. Et nedlastet dokument som åpnes i en ekstern viser, arver ikke nettleserens rute; det bruker systemets, som kan være VPN-en, LAN-et eller ingenting. Den videregivelsen er en vanlig og stille måte innhold du ville holde inne i eksperimentet reiser ut av det. Bestem om den eksterne viseren er en del av eksperimentet eller ikke, og hvis ikke, hold filen inne i nettleseren.

Sjekk 3: bruk en nyttelast det er trygt å miste

Nettverkssjekker bør bruke sider som ikke krever en personlig konto, fordi en kontøkt gjør en rutetest til en autentisert hendelse på noen andres server. En sjekkside som returnerer den tilsynelatende utgangen din, er nok for rutespørsmålet.

Konkret bruker curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip det samme SOCKS-endepunktet som nettleseren bruker, og returnerer utgangen den ser, noe som skiller et nettleserproblem fra et Tor-problem. ss -tnp på maskinen viser hvilken prosess som snakker med hvilken adresse, og det er sjekken som fanger applikasjonen du glemte. Ingen av kommandoene krever innlogging, og begge kan gjentas. Hold resultatene som et før-og-etter-par i stedet for én enkelt observasjon.

Sjekk 4: gjenopprett vanlig bruk med vilje

Fjern testunntak og midlertidige innstillinger gjennom komponenten som opprettet dem, ikke gjennom et annet verktøy som tilfeldigvis tilbyr en lignende bryter.

Sjekk deretter de normale applikasjonene, inkludert DNS-oppslag og enhver privat ressurs som arbeidsruten trenger. En test som ender med fungerende surfing men ødelagte interne navn, er ikke ferdig.

Hold notater som er gode nok til å gjenskape et nyttig funn, og ikke mer. Registrer VPN-profilen som brukes, appunntakene, utgangsadressene som ble observert og tidspunktet; ikke registrer kontoopplysninger eller innholdet i sidene du besøkte. Hvis kombinasjonen ikke gir klar nytte, ikke la ekstrainnstillingene være aktive bare fordi én testside ble lastet. Et eksperiment som blir stående, blir en udokumentert del av produksjonsruten.

Tor Projects veiledning om håndtering av identiteter i Tor Browser er referansen for hva nettleseren holder atskilt på egen hånd, og den er verdt å lese før du legger på enda et lag.

En test er ferdig når den tiltenkte konfigurasjonen er gjenopprettet eller den nye konfigurasjonen er forstått, ikke når én applikasjon slutter å vise en feil. Det er forskjellige sluttilstander, og bare én av dem er trygg å forlate. Hvis du ikke kan beskrive den nåværende ruten til hver applikasjon du listet opp i sjekk en, kjører eksperimentet fortsatt. Lukk det med vilje.