Kan een VPN-operator zien welke sites u bezoekt?

Vraag wat de VPN kan zien en het antwoord hangt af van waar u in het pad staat. Op de sessielaag heeft de operator authenticatiegebeurtenissen en byte-tellingen. Op de pakketlaag heeft hij bestemmingsadressen en timing. Op de DNS-laag kan hij de namen zelf hebben. Elke laag beantwoordt een andere vraag, en geen enkele schakelaar verplaatst u ertussen.

Bepaal de laag voordat u iets beweert

Dezelfde verbinding levert op elk punt andere registraties op, en een uitspraak over privacy is alleen zinvol als die het punt noemt. Lees de tabel kolom voor kolom: wat op die laag bestaat, wat een operator daar kan zien en wat diezelfde registraties nog steeds niet kunnen vertellen.

Eén laag als het volledige beeld lezen is het begin van zowel overdreven claims als valse geruststelling. Een provider die zegt geen browsegeschiedenis te loggen kan nauwkeurig zijn over URL-logging en toch sessieregistraties bewaren, en een pakketopname die alleen adressen toont wordt zonder reverse lookups en giswerk geen browsegeschiedenis.

Als u een beleid beoordeelt, zoek dan de zin die elke laag beschrijft. Als het beleid ze niet scheidt, vraag dan welke registraties bestaan in plaats van een algemene uitspraak over versleuteling te accepteren.

Sessie-inventaris: wat een standaard OpenVPN-server bewaart

Standaard legt een OpenVPN-server geen verkeer vast. De normale uitvoer is een sessie-inventaris: het account dat zich authenticeerde, het bronadres waar het vandaan kwam, tijdstempels voor begin en einde, het uitgegeven tunneladres en de bytetotalen in beide richtingen. Dat is een inventaris van sessies, geen lijst van bestemmingen.

Logopties kunnen detail toevoegen. Een hoger uitgebreidheidsniveau schrijft meer over de handshake, en een statusbestand kan verbonden clients opsommen, maar geen van beide maakt de server een transparante proxy. URL's produceren vereist TLS beëindigen of een expliciete proxy draaien, en beide veranderen de vertrouwensregeling in plaats van een verborgen functie aan te zetten.

Daarom is de nauwkeurige versie van de bewering geen browse-log smaller dan hij klinkt. De server kent de pagina niet, maar weet wel dat er een sessie bestond en ongeveer hoeveel data erdoor ging. Of die sessieregistratie wordt bewaard, en hoe lang, is een aparte beleidsvraag.

Binnen- en buitenpakketten zijn verschillend bewijs

Een pakketopname is de manier om te zien wat er werkelijk door de tunnel gaat. Noem op de server de tunnelinterface en schrijf naar een bestand dat offline kan worden geanalyseerd:

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

Dat bestand bevat ontsleuteld binnenverkeer: het tunneladres van de client als bron, het bestemmingsadres en de poort, pakketgroottes en timing. Het bevat het HTTP-pad of de responsbody niet, tenzij TLS ergens is beëindigd, en het zijn gevoelige gegevens waarvan het bewaren een beleidsbeslissing is en geen debuggemak.

Een opname op de fysieke interface laat iets anders zien. Daar ziet u buitenpakketten gericht aan het VPN-eindpunt, met de versleutelde payload erin. Onverwante adressen in dat bestand zijn normaal zodra er een virtuele adapter is, omdat het tunnelapparaat de binnenstromen draagt terwijl het versleutelde transport de buitenste draagt.

Vraag op welke vraag de opname antwoord moet geven. Het gebruik van de tunnel door een toepassing is zichtbaar op de virtuele adapter; de bereikbaarheid van de tunnel tot het eindpunt is zichtbaar op de fysieke. Een van beide bestanden als het volledige beeld gebruiken levert conclusies op die de gegevens niet kunnen dragen.

DNS is de plek waar namen zichtbaar worden

DNS blijft de praktische uitzondering. De resolver ziet de namen die hij moet oplossen, dus wie hem beheert leert welke sites een client opzoekt, zelfs wanneer de latere verbindingen versleuteld zijn. Een tunnelopname toont adressen; de resolver toont namen.

Controleer welk adres de resolver gebruikte om een externe dienst te bereiken. Het antwoord is het uitgaande adres van de resolver, en vergelijking met de VPN-uitgang vertelt u of de query door de tunnel ging:

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

Als dat adres overeenkomt met de lokale verbinding en niet met de tunneluitgang, omzeilde de opzoeking de VPN en was de naam zichtbaar op het lokale pad. Herhaal de controle na een clientupdate, want een nieuwe versie kan veranderen welke resolver het profiel installeert.

Versleutelde DNS verplaatst de zichtbaarheid in plaats van die te verwijderen. Het netwerk ziet de query niet meer, maar de resolver nog wel, en de vertrouwensvraag wisselt simpelweg van handen. De TLS-servernaam in de handshake van de verbinding is een ander gedeeltelijk signaal: die overleeft vaak zelfs wanneer de payload ondoorzichtig is, dus bestemmingsadressen zijn niet de enige metadata die een doorsturende server kan waarnemen.

Drie soorten registraties en wie ze kan lezen

Sessieboekhouding, registraties per naam en lekbewijs zijn drie verschillende producten met drie verschillende verplichtingen. Sessielogs zijn goedkoop en weinig gevoelig, en ze beantwoorden wie zich wanneer verbond. Registraties per naam vereisen een loggende resolver of een expliciete proxy, en ze scheppen een openbaarmakingsplicht tegenover de betrokkenen. Lekbewijs is een test aan de clientzijde die vergelijkt wat de resolver onthult met de tunneluitgang.

Noteer welke van de drie u draait, wie het kan lezen en hoe lang het blijft. Uitspraken dat een dienst geen logs bijhoudt beschrijven één laag, en ze blijven alleen binnen die reikwijdte waar. Dezelfde provider kan nauwkeurig zijn over sessies en onjuist over DNS.

Houd de test reproduceerbaar: dezelfde resolversquery, dezelfde opname-interface en dezelfde vergelijking. Een privacyclaim die niet op een genoemde laag kan worden getest is een slogan, geen operationeel feit.