Tor via VPN: wie ziet je IP, en wie ziet dat je Tor gebruikt?

Je verbindt de VPN-client, wacht op de tunnel en opent dan Tor Browser om een circuit te bouwen. Juist die gewone volgorde bepaalt wie wat ziet. In die volgorde groet de Tor-ingangsrelay het adres van je VPN-uitgang, en je VPN-provider groet een openbare guard-relay. Doe het omgekeerd en beide waarnemers veranderen. Beide volgordes zijn de moeite waard, want clientinstellingen breken stilletjes de volgorde die mensen dachten dat er was, en de controle die dat vangt is in beide gevallen hetzelfde.

Begin bij de volgorde, niet bij het product

Twee opstellingen heten „VPN met Tor“, en alleen de eerste is gebruikelijk. Bij Tor via VPN staat de tunnel al als Tor start, dus stuurt het tor-proces zijn guard-verbinding de tunnel in zoals al het andere uitgaande verkeer. Bij VPN via Tor komt Tor eerst omhoog en de VPN-sessie zelf reist door het circuit en komt bij de provider aan vanuit een Tor-uitgang.

Wat tussen beide verandert, is welk adres aan het verre uiteinde van de buitenste schakel staat. Elke waarnemer ziet alleen de vorige hop, nooit het hele pad: de guard ziet wie verbinding met hem maakte, en de VPN-server ziet wie verbinding met hem maakte. Tor draagt je lokale tunneladres niet naar buiten, en er is geen veld in het protocol waar dat zou kunnen.

In beide volgordes ziet de bestemmingswebsite nog steeds een Tor-uitgang, en geen van beide volgordes verandert wat die site van je login leert. Het verschil blijft beperkt tot de twee randen.

Wat de Tor-ingangsrelay ziet

De ingang, of guard, accepteert een gewone TCP-verbinding op een relaypoort en begint een TLS-handshake met de client. Bij een Tor-via-VPN-opstelling is de bron van die verbinding je VPN-uitgang. Bij een Tor-eerst-opstelling is dat het adres dat je machine gebruikte om het Tor-netwerk te bereiken, meestal je thuisverbinding.

Dat beantwoordt de IP-helft van de vraag, maar alleen als de tunnel de verbinding echt heeft gedragen. Het Tor-proces bereikt de guard met zijn eigen socket, en die socket valt niet onder de proxyinstellingen van Tor Browser. De browser praat met het meegeleverde tor-proces via SOCKS op 9150, en tor opent dan zijn eigen verbinding met de routingtabel van de kernel. Een Socks5Proxy-regel in torrc, of een clienttransport, verandert dat pad. Niets anders.

Op Linux kun je het antwoord van de machine aflezen. Vraag de kernel welke interface hij zou gebruiken voor een willekeurig openbaar adres, en kijk dan naar het lokale adres van de tot stand gebrachte verbinding:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Als de route dev wg0 of dev tun0 zegt, en het lokale adres op de tot stand gebrachte verbinding is het tunneladres, dan zit Tor binnen de VPN. Als de route je fysieke interface noemt, zit hij erbuiten, wat de eigen indicator van de client ook beweert.

Wat je VPN-provider kan zien

De provider beëindigt je VPN-sessie, dus ziet hij de adressen waarmee je verbindt. Guard-relayadressen worden in de openbare consensus gepubliceerd en hun poorten zijn bekend, dus er een matchen is een lijstzoekopdracht, geen diepe pakketinspectie. Een provider hoeft Tor niet te breken om te weten dat een sessie Tor is.

Wat hij niet ziet, is de rest van het circuit. De middenrelay en de uitgang worden binnen Tor gekozen, en de provider behandelt alleen de schakel naar de guard. Pagina-inhoud blijft binnen TLS die bij de uitgang eindigt, en naamresolutie voor Tor-verkeer gebeurt ook bij de uitgang, dus er is geen DNS-query bij de provider om met een bestemming te correleren.

Bruggen met obfs4 veranderen de zoekopdracht, niet de topologie. Een brugadres ontbreekt in de openbare relaylijst en het verkeer wordt gevormd om niet op Tor te lijken, dus een operator die alleen adressen vergelijkt, markeert hem niet. De sessie komt nog steeds van je VPN-client, en de provider ziet nog steeds één eindpunt, één volume en één tijdschema.

Vermogen is geen bewaarbeleid

Een operator die een verbinding kan waarnemen, heeft niet beloofd die te bewaren. Loggen is een aparte beslissing, vastgelegd in een beleid, beperkt door jurisdictie en alleen controleerbaar met bewijs dat je al vertrouwt. Een no-logs-label verandert de hierboven beschreven netwerkrol niet.

Accountidentiteit is meestal belangrijker dan het uitgangsadres. Als je met een e-mailadres bent ingelogd, of met een kaart hebt betaald, kan de provider de sessie aan je koppelen zonder één bestemming te loggen. Uitgangs-IP's roteren doet daar niets aan.

Controleer de dekking voordat je een van beide antwoorden vertrouwt

De meeste mensen die denken Tor via VPN te draaien, draaien er maar een deel van. Split tunneling die Tor Browser uitsluit, een kill switch die de browser dekt maar niet de tor-dienst, een opstarteenheid die draait voordat de tunnel omhoog is, en een IPv6-pad om de tunnel heen zijn de gebruikelijke vier.

Het statusscherm van de client lezen test geen van alle. De test die dat wel doet: laat Tor Browser draaien, haal de tunnel neer en kijk of de guard-verbinding op de fysieke interface overleeft.

De volgorde waarin ik controleer, en stop bij de eerste fout:

• ip route get 203.0.113.10 geeft het tunnelapparaat terug.
• ss -tnp | grep -i tor toont de guard-verbinding met een lokaal tunneladres.
• ip -6 route heeft geen standaardroute buiten de tunnel, of IPv6 staat uit in de client.
• De VPN laten vallen beëindigt of leidt de tor-verbinding om in plaats van hem op de fysieke schakel te laten.

Welke volgorde past bij wat je verdedigt

Beide volgordes verbergen iets en leggen iets bloot, dus het antwoord is een keuze over de waarnemer die je belangrijk vindt.

Lees het kolom voor kolom tot een rij past bij wat je probeert te voorkomen. Als de zorg een lokaal netwerk of een ISP is die Tor vastlegt of blokkeert, regelt Tor via VPN dat. Als de zorg is dat de VPN-operator je thuisadres leert, regelt VPN via Tor dat, en betaalt daarvoor door Tor-gebruik aan je eigen netwerk en je thuisadres aan de guard bloot te leggen.

Geen van beide opstellingen laat beide randen blind. Een waarnemer toevoegen haalt er geen weg. De notitie van het Tor Project over een VPN met Tor draaien zegt hetzelfde van de andere kant: de tunnel verandert wie er vertrouwd wordt en welke faalpaden bestaan, dus het is geen upgrade om toe te voegen zonder te beslissen wat je wilde verbergen.

Beslis eerst de waarnemer, kies dan de volgorde, en verifieer met ip route get en ss in plaats van met de indicator van de client. Als de waarnemer iemand is die de VPN-provider zelf kan dwingen, maakt geen enkele volgordekeuze dat goed.