VPN in Tor, Tor in VPN: waarom de keten breekt
Wanneer een VPN, Tor en een proxy worden gestapeld, bepaalt de volgorde wat er wordt opgelost en wat er wordt gedragen. Vind de eerste gebroken grens voordat je alle drie verandert.
Een VPN, Tor en een applicatieproxy stapelen voelt als privacy vermenigvuldigen, en het vermenigvuldigt het aantal plekken waar een verbinding kan sterven. Het gebruikelijke resultaat is een browser die draait terwijl drie hulpmiddelen zichzelf gezond melden. Als je alle drie instellingen tegelijk verandert, verwijder je de enige aanwijzing over welke van hen liegt.
Teken eerst het bedoelde pad in volgorde, en benoem welk programma elke verbinding opent en welke naam bij elke stap wordt opgelost.
Lagen tellen niet op, ze beïnvloeden elkaar
Een VPN vóór Tor betekent dat de inkomende verbinding van de Tor-client binnen de tunnel reist. Een VPN die door Tor wordt gedragen betekent dat het eigen eindpunt van de VPN-client via Tor bereikbaar moet zijn, wat een heel andere eis is. De proxy van de browser voegt nog een sprong toe waar het besturingssysteem niets van weet. Drie opstellingen, drie aparte afhankelijkheidslijsten.
Elke opstelling verandert wat kan worden opgelost, wat kan worden gedragen en wie het eerste pakket ziet. Slechts één ervan kan de configuratie zijn die je bedoelde.
Voeg ook het directe pad toe aan het diagram. Een terugvalroute, een uitzondering voor gesplitste tunnel of een proxy-omweg kunnen een pagina laten laden terwijl ze de keten die je wilde testen stil overslaan, en dat succes misleidt meer dan de fout.
De volgorde bepaalt wat er gedragen kan worden
Tor draagt TCP-stromen via zijn SOCKS-interface, en een client die de proxy vraagt de hostnaam op te lossen houdt de opzoeking binnen het circuit. UDP reist in gewone configuraties niet zo, daarom kan een WireGuard-tunnel niet in Tor worden genest zonder een extra TCP-relay in het midden.
OpenVPN kan naar TCP worden gedwongen, dus die opstelling is tenminste beschrijfbaar. Het is ook langzamer en breekbaarder, en de faalmodus bij breuk lijkt precies op een geblokkeerde poort. Verwacht meer tijd te besteden aan het onderscheiden van die twee dan aan het repareren van een van beide.
Oplossen is de andere helft. Met --socks5-hostname lost de proxy de bestemming op, terwijl gewone --socks5 eerst de lokale resolver vraagt en de naam buiten het circuit lekt. Precies die ene vlag bepaalt of de naamopzoeking bij de keten of bij je provider hoort.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
De eerste gebroken grens vinden
Test de fasen in de volgorde waarin de pakketten reizen, met onschuldige verzoeken, en stop bij de eerste die faalt. Noteer welke opdracht eerst liep, want de volgorde is deel van het bewijs. Twee opdrachten scheiden een dood circuit van een dode uitgang:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
De eerste meldt of een verzoek überhaupt via de SOCKS-proxy wordt voltooid, en de tweede toont het adres dat het netwerk op dit moment presenteert. Als de eerste faalt en de tweede slaagt, zit het probleem bij de Tor-client of daarvoor. Als beide slagen en de browser toch faalt, gebruikt de applicatie een ander pad dan de shell.
Een pagina met het openbare IP beschrijft ook alleen de laatste zichtbare uitgang. Hij kan niet zeggen hoeveel sprongen eraan voorafgingen, dus combineer hem met de ondersteunde statusuitvoer van elk hulpmiddel in plaats van één getal als diagram te behandelen.
Wanneer stoppen met lagen toevoegen
Als je niet in één zin kunt zeggen wat een laag bijdraagt, verwijder hem. Een keten waarvan het doel onduidelijk is, is een keten die niemand om drie uur 's nachts kan debuggen, en de privacywinst van een onverklaarde sprong is meestal kleiner dan de beschikbaarheid die je verliest.
Als een laag zijn plek echt verdient, test hem dan eerst alleen, voeg daarna de volgende toe en bevestig het pad opnieuw met dezelfde twee opdrachten. Herstel de volledige keten voor gewoon gebruik, en houd TLS-validatie en authenticatie ingeschakeld; een certificaatwaarschuwing die wordt geaccepteerd om een pagina te laten laden is een routeringsomweg, geen reparatie. Noteer de volgorde die je koos terwijl die nog vers is.
Schrijf die volgorde op, inclusief de resolver die bij elke fase antwoordt. Een werkende keten die je kunt beschrijven overleeft de volgende update, terwijl een werkende keten die je door te proberen in elkaar zette daarmee verdwijnt. Voeg de datum en de versies toe, zodat een latere storing vergeleken kan worden met een bekend goede toestand in plaats van uit het geheugen te worden bediscussieerd. Tien regels in een tekstbestand besparen een avond gissen.