Sådan holder du Tor Browser-tests adskilt fra VPN-trafik

Eksperimentet er ikke browseren; det er hele sættet af ruter på maskinen, mens browseren kører. Hvis du ændrer en global proxy eller en rute for at teste Tor Browser med en VPN, arver hver anden applikation ændringen, inklusive dem der synkroniserer filer og tjekker mail i baggrunden. Det sikre mønster er at give eksperimentet sin egen applikation, sin egen profil og sin egen rute og at vide præcis, hvordan man sætter alt tilbage. En offentlig IP-side fortæller dig, at én udgang blev brugt; den fortæller ikke, hvad resten af maskinen gjorde.

Kontrol 1: navngiv de tre forbindelser

Navngiv dem, før du rører nogen indstilling. Den normale rute er det, dine arbejdsapplikationer bruger i dag; den eksperimentelle rute er det, du vil have Tor Browser til at bruge; den tilsigtede fejladfærd er det, der skal ske, når et lag falder.

Skriv de tre ned på ét sted, inklusive hvilken applikation der hører til hvilken rute. Årsagen er ikke bureaukrati: de fleste utilsigtede lækager under denne slags test kommer fra en applikation, som ingen huskede kørte, ikke fra browseren, der testes. En adgangskodeadministrator, en chatklient og en filsynkroniseringsdaemon er alle baggrundstrafik, der tager den rute, systemet giver dem. At navngive dem er det, der gør grænsen virkelig.

Kontrol 2: hold hver indstilling hos sit eget program

Tor Browsers understøttede konfiguration er ikke det samme som en systemproxyindstilling, og den er bevidst ikke designet til at blive peget på en vilkårlig proxy fra miljøet.

En miljøvariabel eller en browserudvidelse kan skabe en tredje rute, som hverken browserdokumentationen eller dine noter beskriver. Foretræk den understøttede indstilling inde i applikationen frem for en global tilsidesættelse.

Det samme gælder alt, hvad browseren giver videre. Et downloadet dokument, der åbnes i en ekstern fremviser, arver ikke browserens rute; det bruger systemets, som kan være VPN'en, LAN'et eller intet. Den videregivelse er en almindelig og stille måde, hvorpå indhold, du ville holde inde i eksperimentet, rejser ud af det. Beslut, om den eksterne fremviser er en del af eksperimentet eller ej, og hvis ikke, så hold filen inde i browseren.

Kontrol 3: brug en nyttelast, der er sikker at miste

Netværkskontroller bør bruge sider, der ikke kræver en personlig konto, fordi en kontosession gør en routingtest til en autentificeret begivenhed på en andens server. En kontrolside, der returnerer din tilsyneladende udgang, er nok til routing-spørgsmålet.

Konkret udøver curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip det samme SOCKS-endepunkt, som browseren bruger, og returnerer den udgang, den ser, hvilket adskiller et browserproblem fra et Tor-problem. ss -tnp på maskinen viser, hvilken proces der taler med hvilken adresse, og det er den kontrol, der fanger den applikation, du glemte. Ingen af kommandoerne kræver login, og begge kan gentages. Gem resultaterne som et før-og-efter-par i stedet for en enkelt observation.

Kontrol 4: gendan normal brug med vilje

Fjern testundtagelser og midlertidige indstillinger gennem den komponent, der oprettede dem, ikke gennem et andet værktøj, der tilfældigvis tilbyder en lignende kontakt.

Kontroller derefter de normale applikationer, inklusive DNS-opslag og enhver privat ressource, som arbejdsruten har brug for. En test, der slutter med fungerende browsing men brudte interne navne, er ikke færdig.

Hold noter, der er gode nok til at genskabe et nyttigt fund, og ikke mere. Registrer den anvendte VPN-profil, app-undtagelserne, de observerede udgangsadresser og tidspunktet; registrer ikke kontooplysninger eller indholdet af de sider, du besøgte. Hvis kombinationen ikke giver klar fordel, så lad ikke dens ekstra indstillinger være aktive, bare fordi én testside blev indlæst. Et eksperiment, der bliver på sin plads, bliver en udokumenteret del af produktionsruten.

Tor Projects vejledning om håndtering af identiteter i Tor Browser er referencen for, hvad browseren selv holder adskilt, og den er værd at læse, før du lægger endnu et lag ovenpå.

En test er færdig, når den tilsigtede opsætning er gendannet, eller den nye opsætning er forstået, ikke når én applikation holder op med at vise en fejl. Det er forskellige sluttilstande, og kun én af dem er sikker at efterlade. Hvis du ikke kan beskrive den aktuelle rute for hver applikation, du listede i kontrol et, kører eksperimentet stadig. Luk det med vilje.