VPN — What It Does & Doesn't Do

Without a VPN, your packets leave the NIC, hit the local gateway (home router or café AP), then your ISP, then the internet, then the site. On-path observers who can see those hops may see destination IPs, SNI or DNS names (unless encrypted DNS / TLS 1.3 Encrypted Client Hello is in play), timing, and sizes. A VPN wraps the inner packets so the local path mostly sees "encrypted blob to vpn.provider.example." Inner destinations are unpacked at the VPN server. That is a shift of trust. You stopped the café and (often) the ISP from reading the inner map. You gave the VPN vendor the ability to see destination IPs, timing, and — if the inner site is not HTTPS — even content. HTTPS still matters inside the tunnel: the VPN hop is not end-to-end with the website. End-to-end TLS is still between you and the site. Think of the VPN as an armored truck to a depot. The depot staff can see where the truck goes next. The website still opens the package if you logged in.

WireGuard, OpenVPN, and IKEv2 differ in speed and roaming; they do not change the trust shift. A kill switch is a local firewall rule: if the tunnel drops, do not leak inner destinations on raw Wi-Fi. Split tunneling (some apps outside the VPN) is a leak by design — fine for a game, bad if you assumed "VPN on" meant the browser was inside. Check YOUR client. Do not capture café guests to "test" their tunnels.

On untrusted Wi-Fi, the useful property is: a casual observer on the same LAN, and the hotspot operator, should not get a clear list of the sites inside the tunnel. They still see that you are using a VPN, how much you send, and when. Metadata of the outer session is not "nothing." DNS must go through the tunnel or through encrypted DNS you chose; if DNS still goes to the café's resolver in cleartext, the operator gets names even when TCP is tunneled. Reputable clients force tunnel DNS. Cheap free apps sometimes do not. The destination website sees the VPN server's public IP, not your home or café IP — unless the client leaks (WebRTC is a classic leak of the real address unless the browser is locked down). The site also sees cookies, login sessions, and your account. A VPN is not a new identity. "I had the VPN on" does not unsay a password you typed into the real Google login, and it does not unsay a password you typed into a look-alike. Extra anonymity tools (Tor, careful compartmentation) are a different stack. This course is not teaching you to hide crimes. It is teaching you when a tunnel helps a traveler and when it is theater.

A VPN does not scan files, does not block malicious websites by magic, and does not replace a password manager or 2FA. Some vendors bundle extra "threat protection"; treat that as a separate product with a separate claim, not as the tunnel itself. Phishing is a name-and-human problem. TLS to https://bank-secure-login.example is valid for that name. The tunnel will encrypt your trip to the fake name just as happily as to the real bank. Malware that is already on the device uses the same NIC. The tunnel does not inspect it unless you bought a filter that actually does — and even then, it is not a substitute for not running the attachment. Free VPNs with huge permission lists on phones are often logging and ad businesses. If the product has no sustainable business other than "you," assume logs. A no-logs policy is a claim; independent audits and jurisdiction matter more than a homepage badge. Paid, boring, audited is the adult choice. Using a VPN to break the law is still breaking the law. This lesson will not help you "hack the hotspot," spoof a café, or cloak fraud. The tunnel is a privacy control for a path you are allowed to use.

Helps: untrusted Wi-Fi (airport, hotel, café) where you do not want the local operator or a neighbor to map your inner destinations; ISPs that log or inject; a need to move your apparent IP off a hostile local network before you fetch mail. Still use HTTPS. Still check the name. Still prefer cellular/hotspot for banking if you can. Does not help: logging into Google, your bank, or work SSO and expecting "anonymity"; stopping malware; fixing a reused password; making a phishing page safe; hiding from the site you authenticated to; replacing browser tracker blocking from the last lesson. The vendor can still see metadata of what you resolve and connect to. If that vendor is compelled or compromised, the depot logs are the new path observer. Choose the depot on purpose.

You will query a public echo of YOUR address and HTTPS headers to example.com. That is your client talking to infrastructure that exists to answer "who am I on the internet?" You are not scanning the café. You are not nmap'ing neighbors. If you do not have a VPN account, still run the without-VPN checks and write "no tunnel installed" — that is an honest score. Do not sign up for a shady free app to complete the lab.

curl -I https://example.com

curl -sS --max-time 10 https://ifconfig.me

dig example.com +short

mkdir -p "$HOME/cyberlium-lab"
{
  echo "date: $(date -Iseconds 2>/dev/null || date)"
  echo "https_example_headers: (paste status line only, not cookies)"
  echo "ip_without_vpn:"
  echo "ip_with_vpn: (or 'no tunnel installed')"
  echo "dns_resolver_note: (ISP vs tunnel DNS — if you can tell)"
  echo "kill_switch_enabled: yes/no/unknown"
  echo "remember: VPN is not antivirus and not a crime cloak"
} > "$HOME/cyberlium-lab/vpn-notes.txt"
chmod 600 "$HOME/cyberlium-lab/vpn-notes.txt"

You can draw the hop (device → VPN server → site), name what the local operator loses and what the vendor and the destination still see, and refuse the myths: not antivirus, not a phishing shield, not anonymity at login, not a crime cloak. Next — Public WiFi — shared Layer 2, rogue APs with similar SSIDs, captive portals, and why HTTPS plus a tunnel still beat "hack the hotspot" theater. Carry Topic 3: you do not nmap the café.