OPSEC52 / Week 1 — VPN exit discipline

If your exchange login and your Tor session share an endpoint, you’ve built the bridge yourself. Rotate servers, separate contexts, assume everything connects eventually.

Threat model: a correlator (chain analyst, ISP-level adversary, exchange compliance team) trying to link otherwise-unconnected accounts via shared exit IP. Difficulty: beginner · Cost: $0 (with the VPN you already have) · Published: 2026-06-02

The practice

A VPN does two things, and most users only think about the first one. It hides your real IP from the destination, and it gives the destination a consistent exit IP for every connection you make through that tunnel. If you don’t rotate, that second property leaks more than the first one protects.

Concrete example: you log into your KYC exchange (Bybit, Kraken, whoever) from VPN exit 199.21.x.y on a Tuesday. On Wednesday you open Tor Browser, also egressing the same VPN exit (because you’re tunneling Tor over VPN for the “extra hop”). You sign into a privacy forum, send a Monero address to a buyer, do whatever you do in your private context. Exchange compliance + forum operator + your VPN provider’s logs (if any) now share a partial timeline: same exit IP, two different identity contexts, hours apart. Correlation is trivially possible — even if the VPN provider itself never sees you. The adversary doesn’t need to see you; they need to see the pattern.

A VPN exit is a fingerprint. Re-using it across identity contexts is no different from re-using a username.

The fix is operational, not technical. Most modern VPN clients let you select an exit server (or country) per profile. You don’t need a different VPN provider for each context — you need a different exit per context.

How to apply it today

Map your identity contexts. Three minimum: KYC stack (exchanges, banks, anything tied to your real name), pseudonymous stack (forums, X account, GitHub if pseudonymous), no-identity stack (Tor, privacy services, Monero swaps). Some users add a fourth for research stack (just reading, no logins).
Assign an exit (or country) per context. Mullvad, IVPN, Proton all let you bookmark a city or specific server. Pick three or four cities you’ll consistently use. Don’t share cities across contexts.
Build the habit of switching when the context switches. Easiest pattern: dedicated browser profiles tied to each context, each with the VPN profile pre-selected. Firefox containers, Brave profiles, even separate browser apps (Tor Browser for no-identity, Brave for pseudonymous, regular Chrome for KYC — the trust boundary doubles as the visual cue).
Rotate within each context periodically. Even within your pseudonymous stack, swap city every few weeks. Avoids long-term static fingerprinting.
For Tor over VPN, pick a VPN exit you don’t use anywhere else. Tor’s exit-IP rotation already handles destination-side; what matters is the entry-side (the IP your VPN gives Tor). That entry should never appear in any non-Tor connection.

Common mistakes

Setting “auto” or “fastest server” globally. Convenience-first VPN routing picks the same exit repeatedly. Convenience kills exit discipline.
Sharing exit across the KYC and pseudonymous stacks. This is the most common slip. Once a single login crosses the streams, the rest of the stream is correlated forever.
Trusting that “no-logs” means “no IP correlation possible.” No-logs is about the VPN provider’s records. The destination still sees your exit IP. The correlation is downstream, not at the provider.
Forgetting mobile. Your phone connects to dozens of services. If it auto-VPNs through the same exit your laptop uses for Tor, you’ve linked them. Mobile needs its own context map.
Using a “dedicated IP” for any pseudonymous identity. Dedicated IPs are unique to you. They are the worst possible choice for OPSEC.

VPN exit discipline — stop using one exit for everything

OPSEC52 / Week 1 — VPN exit discipline

The practice

How to apply it today

Common mistakes

See also