Hoe je het gebruikte VPN-uitgangsadres vastlegt en verifieert

Vraag een desktop-VPN-client welke servers je hebt gebruikt en het eerlijke antwoord is meestal een locatienaam. Die naam is het ingangspunt dat je hebt gekozen, en het adres waarlangs je verkeer naar buiten ging kan een heel andere machine zijn. Niets in de app is ontworpen om het tweede nummer te bewaren, dus het verslag moet op het moment van gebruik worden opgebouwd. Er bestaan twee benaderingen, en slechts één ervan overleeft een supportcase.

Twee verslagen, waarvan er maar één bestaat

De eigen weergave van de client is op zijn best een lijst van gekozen locaties met tijdstempels. Dat is een ontwerpbeslissing en geen vergissing: adressen zijn operationeel detail, ze roteren tussen toewijzingen, en het blootleggen van de koppeling maakt zowel support als misbruikbestrijding moeilijker. Aanbieders zetten cloudinstanties voor hun netwerken juist zodat het eindpunt kan verhuizen zonder dat iemand het weet. Wat de app je toont, is de keuze die je maakte, niet de route die het nam.

Het verslag dat je zelf kunt opbouwen is een lokaal bestand met één openbaar adres en één UTC-tijdstempel per regel. Het is kleiner, lelijker en veel nuttiger, omdat het precies beschrijft wat een buitenstaander ook kan zien.

Optie A: het uitgangsadres zelf vastleggen

Een echodienst geeft het bronadres terug waarvandaan het verzoek aankwam, en dat is per definitie het uitgangsadres. Voer de meting uit nadat de tunnel meldt dat hij verbonden is, want een client die “verbonden” zegt voordat routes en DNS stabiel zijn, legt het adres van vóór de tunnel vast en vergiftigt het log vanaf de eerste regel.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Twee details maken dat fragment bruikbaar in plaats van decoratief. Tijdstempel en adres staan op één regel, zodat een latere parse geen records hoeft te koppelen, en umask 077 houdt het bestand vanaf het moment van aanmaken privé. Voer het één keer per verbinding uit in plaats van één keer per opstart, en houd één bestand per apparaat aan.

Het log legt vast wanneer je een tunnel gebruikte en uit welk netwerk je verscheen, wat dichter bij browsegeschiedenis ligt dan bij een teller. Kies een bewaartermijn die je kunt verdedigen, houd het bestand buiten gedeelde syncmappen en ruim het bewust op.

Optie B: de aanbieder om een geschiedenis vragen

Sommige aanbieders bewaren verbindingslogs en beantwoorden een supportvraag met een tijdstempel en een servernaam. Dat verslag beschrijft hun infrastructuur en niet jouw verkeer, en het is alleen zo goed als hun bewaartermijn en hun bereidheid om te kijken. Het beschrijft bovendien een sessie, geen verzoek. Het venster is meestal kort, en het wordt gemeten vanaf de kant van de aanbieder van de tunnel.

Aanbieders die adverteren met geen logging kunnen dit op verzoek niet leveren, en een lijst van recente locaties aan de clientkant is iets anders. Een no-logaanbieder om een uitgangsadres vragen eindigt meestal met een uitleg waarom die gegevens niet bestaan.

Wat elk verslag in een supportcase kan bewijzen

De twee verslagen beantwoorden verschillende vragen, en in de tabel houdt de vergelijking op academisch te zijn.

Alleen de eerste kolom is in jouw hand. Een verslag van de aanbieder kan bevestigen dat een account op een bepaald tijdstip verbonden was, maar het kan niet bevestigen welke verzoeken de tunnel gebruikten, en het zal geen adres noemen dat de aanbieder als operationeel detail beschouwt. Geen van beide verslagen identificeert een persoon, want een gedeeld uitgangsadres kan in dezelfde minuut veel klanten dragen.

Vergelijk beide met een basislijn voordat je een van beide vertrouwt

Een adres op zichzelf bewijst niets. Leg het directe adres vast vóór het verbinden, het getunnelde adres erna, en vergelijk ze. Identieke waarden betekenen dat de tunnel dat verzoek niet draagt, hetzij door een split-tunnel, hetzij door een overheersende proxy of een client die terugviel op een direct pad.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Herhaal de vergelijking voor DNS en voor IPv6, want een adresecho bewijst het pad van één HTTP-verzoek en niets over welke resolver antwoordde. Een apparaat dat op een van beide lekt, kan op de andere volkomen gezond lijken.