Vra 'n lessenaar-VPN-kliënt watter bedieners jy gebruik het, en die eerlike antwoord is gewoonlik 'n pleknaam. Daardie naam is die ingangspunt wat jy gekies het, en die adres waar jou verkeer uitgegaan het, kan 'n heeltemal ander masjien wees. Niks in die toepassing is ontwerp om die tweede nommer te hou nie, so die rekord moet op die oomblik van gebruik gebou word. Daar bestaan twee benaderings, en net een van hulle oorleef 'n ondersteuningsgeval.

Twee rekords, en net een van hulle bestaan

Die kliënt se eie aansig is op sy beste 'n lys van gekose plekke met tydstempels. Dit is 'n ontwerpbesluit en nie 'n versuim nie: adresse is bedryfsbesonderhede, hulle roteer tussen toewysings, en die blootlegging van die kartering maak beide ondersteuning en die hantering van misbruik moeiliker. Verskaffers plaas wolkinstanties voor hul netwerke juis sodat die eindpunt kan skuif sonder om enigiemand te sê. Wat die toepassing vir jou wys, is die keuse wat jy gemaak het, nie die roete wat die verkeer gevolg het nie.

Die rekord wat jy kan bou, is 'n plaaslike lêer met een openbare adres en een UTC-tydstempel per reël. Dit is kleiner, leliker en baie nuttiger, want dit beskryf presies dit wat 'n buitestaander ook kan sien.

Opsie A: vang self die uitgangsadres

'n Eggodiens gee die bronadres terug waar die versoek vandaan gekom het, wat per definisie die uitgangsadres is. Voer die opname uit nadat die tonnel verbind rapporteer, want 'n kliënt wat verbind sê voordat roetes en DNS gevestig is, sal die adres voor die tonnel rekord en die log van die eerste reël af vergiftig.

#!/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 besonderhede maak daardie stuk bruikbaar eerder as versierend. Die tydstempel en adres deel een reël, so 'n latere ontleding hoef nie rekords te paar nie, en umask 077 hou die lêer privaat van die oomblik dat dit geskep word. Voer dit een keer per verbinding uit eerder as een keer per selflaai, en hou een lêer per toestel.

Die log teken aan wanneer jy 'n tonnel gebruik het en uit watter netwerk jy verskyn het, wat nader aan blaai-geskiedenis is as aan 'n teller. Kies 'n bewaartydperk wat jy kan verdedig, hou die lêer buite gedeelde sinchroniseer-vouers en verwyder dit doelbewus.

Opsie B: vra die verskaffer om 'n geskiedenis

Sommige verskaffers hou verbindingslogboeke en sal 'n ondersteuningsvraag beantwoord met 'n tydstempel en 'n bedienernaam. Daardie rekord beskryf hul infrastruktuur en nie jou verkeer nie, en dit is net so goed soos hul bewaarvenster en hul bereidheid om te kyk. Dit beskryf ook 'n sessie, nie 'n versoek nie. Die venster is gewoonlik kort, en dit word van die verskaffer se kant van die tonnel gemeet.

Verskaffers wat adverteer dat hulle geen logboeke hou nie, kan dit nie op versoek lewer nie, en 'n kliëntkant-lys van onlangse plekke is nie dieselfde ding nie. Om 'n uitgangsadres by 'n verskaffer sonder logboeke te vra, eindig gewoonlik met 'n verduideliking van waarom daardie data nie bestaan nie.

Wat elke rekord in 'n ondersteuningsgeval kan bewys

Die twee rekords beantwoord verskillende vrae, en dit is in die tabel waar die vergelyking ophou akademies wees.

QuestionYour local logProvider record
Which address did the traffic leave from?Yes, for the moment it was capturedUsually not disclosed
Was the tunnel in use at 14:20?Yes, if the capture ranYes, within the retention window
Why did a location get slower?Yes, by comparing addresses over timeSometimes, as an infrastructure note
Who sent this specific request?NoNo

Net die eerste kolom is in jou beheer. 'n Verskafferrekord kan bevestig dat 'n rekening op 'n gegewe tyd verbind was, maar dit kan nie bevestig watter versoeke die tonnel gebruik het nie, en dit sal nie 'n adres noem wat die verskaffer as bedryfsbesonderheid beskou nie. Nie een van die rekords identifiseer 'n persoon nie, want 'n gedeelde uitgangsadres kan baie kliënte in dieselfde minuut dra.

Vergelyk albei met 'n basislyn voordat jy enigeen vertrou

'n Adres alleen bewys niks. Vang die direkte adres voor verbinding, die tonnelde adres daarna, en vergelyk hulle. Identiese waardes beteken die tonnel dra nie daardie versoek nie, hetsy weens 'n verdeelde tonnel, 'n oorheersende instaanbediener of 'n kliënt wat teruggeval het na 'n direkte 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 die vergelyking vir DNS en vir IPv6, want 'n adres-eggo bewys die pad van een HTTP-versoek en niks oor watter oplosser geantwoord het nie. 'n Toestel wat op een van die twee lek, kan op die ander heeltemal gesond lyk.

Verwante artikels