Kan en VPN-operatör se vilka webbplatser du besöker?

Fråga vad VPN:en kan se, och svaret beror på var du står i vägen. På sessionslagret har operatören autentiseringshändelser och bytant. På paketlagret har den destinationsadresser och tider. På DNS-lagret kan den ha namnen själva. Varje lager svarar på en annan fråga, och ingen enskild växel flyttar dig mellan dem.

Bestäm lagret innan du påstår något

Samma anslutning ger olika poster vid varje punkt, och ett uttalande om integritet är bara meningsfullt när det namnger punkten. Läs tabellen kolumn för kolumn: vad som finns på det lagret, vad en operatör kan se där och vad samma poster fortfarande inte kan berätta.

Att läsa ett lager som hela bilden är början på både överdrifter och falsk trygghet. En leverantör som säger att den inte loggar surfande kan vara korrekt om URL-loggning och ändå behålla sessionsposter, och en paketinsamling som bara visar adresser blir inte en surfhistorik utan omvända slagningar och gissningar.

När du bedömer en policy, hitta meningen som beskriver varje lager. Om policyn inte skiljer dem åt, fråga vilka poster som finns i stället för att acceptera ett allmänt uttalande om kryptering.

Sessionsinventering: vad en vanlig OpenVPN-server behåller

Som standard fångar en OpenVPN-server inte trafiken. Det normala resultatet är en sessionsinventering: kontot som autentiserade sig, källadressen det kom från, tidsstämplar för start och slut, den tilldelade tunneladressen och byttotalerna i varje riktning. Det är en inventering av sessioner, inte en lista över destinationer.

Loggningsalternativ kan lägga till detaljer. En högre detaljnivå skriver mer om handskakningen, och en statusfil kan lista anslutna klienter, men ingen av dem gör servern till en transparent proxy. Att producera webbadresser kräver att TLS avslutas eller att en explicit proxy körs, och båda ändrar förtroendeupplägget i stället för att slå på en dold funktion.

Därför är den korrekta versionen av påståendet om ingen surfinglogg smalare än det låter. Servern känner inte till sidan, men den vet att en session fanns och ungefär hur mycket data som gick genom den. Om den sessionsposten sparas, och hur länge, är en separat policyfråga.

Inre och yttre paket är olika bevis

En paketinsamling är sättet att se vad som faktiskt passerar tunneln. På servern, namnge tunnelgränssnittet och skriv till en fil som kan analyseras offline:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Den filen innehåller dekrypterad inre trafik: klientens tunneladress som källa, destinationsadress och port, paketstorlekar och tid. Den innehåller inte HTTP-sökvägen eller svarskroppen om inte TLS avslutades någonstans, och det är känsliga data vars bevarande är ett policybeslut och inte en felsökningsbekvämlighet.

En insamling på det fysiska gränssnittet visar något annat. Där ser du yttre paket adresserade till VPN-slutpunkten, med den krypterade nyttolasten inuti. Orelaterade adresser i den filen är normala när det finns en virtuell adapter, eftersom tunnelenheten bär de inre flödena medan den krypterade transporten bär de yttre.

Fråga vilken fråga insamlingen ska svara på. En applikations användning av tunneln syns på den virtuella adaptern; tunnelns nåbarhet till slutpunkten syns på den fysiska. Att använda endera filen som hela bilden ger slutsatser som data inte kan bära.

DNS är platsen där namn blir synliga

DNS förblir det praktiska undantaget. Resolvern ser de namn den ombeds lösa, så den som driver den får veta vilka webbplatser en klient söker efter, även när de senare anslutningarna är krypterade. En tunnelinsamling visar adresser; resolvern visar namn.

Kontrollera vilken adress resolvern använde för att nå en extern tjänst. Svaret är resolverns utgångsadress, och en jämförelse med VPN-utgången säger om frågan gick genom tunneln:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Om den adressen matchar den lokala anslutningen och inte tunnelutgången, gick sökningen förbi VPN:en och namnet var synligt på den lokala vägen. Upprepa kontrollen efter en klientuppdatering, eftersom en ny version kan ändra vilken resolver profilen installerar.

Krypterad DNS flyttar synligheten i stället för att ta bort den. Nätverket ser inte längre frågan, men resolvern gör det fortfarande, och förtroendefrågan byter bara händer. TLS-servernamnet i anslutningens handskakning är en annan partiell signal: det överlever ofta även när nyttolasten är ogenomskinlig, så destinationsadresser är inte de enda metadata som en vidarebefordrande server kan observera.

Tre typer av poster och vem som kan läsa dem

Sessionsredovisning, poster per namn och läckagebevis är tre olika produkter med tre olika skyldigheter. Sessionsloggar är billiga och lågt känsliga, och de svarar på vem som anslöt och när. Poster per namn kräver en loggande resolver eller en explicit proxy, och de skapar en upplysningsskyldighet gentemot de berörda. Läckagebevis är ett test på klientsidan som jämför vad resolvern avslöjar med tunnelutgången.

Skriv ned vilken av de tre du driver, vem som kan läsa den och hur länge den finns kvar. Uttalanden om att en tjänst inte för loggar beskriver ett lager, och de är bara sanna inom det omfånget. Samma leverantör kan vara korrekt om sessioner och fel om DNS.

Håll testet reproducerbart: samma resolverfråga, samma insamlingsgränssnitt och samma jämförelse. Ett integritetspåstående som inte kan testas på ett namngivet lager är en slogan, inte ett operativt faktum.