Så loggar och verifierar du den VPN-utgångsadress du använde
Klientappar visar ett platsnamn, inte adressen som din trafik lämnade från. Fånga utgångs-IP:t vid anslutning och jämför det med en direkt baslinje.
Frågar du en VPN-klient för skrivbordet vilka servrar du har använt är det ärliga svaret oftast ett platsnamn. Namnet är den ingångspunkt du valde, och adressen som din trafik lämnade från kan vara en helt annan maskin. Inget i appen är byggt för att bevara det andra numret, så loggen måste byggas i användningsögonblicket. Det finns två angreppssätt, och bara ett av dem överlever ett supportärende.
Två loggar, och bara en av dem finns
Klientens egen vy är i bästa fall en lista över valda platser med tidsstämplar. Det är ett designbeslut och inte en försummelse: adresser är driftdetaljer, de roterar mellan tilldelningar, och att exponera mappningen gör både support och missbrukshantering svårare. Leverantörer sätter molninstanser framför sina nät just för att slutpunkten ska kunna flytta utan att någon får veta det. Det appen visar dig är det val du gjorde, inte den väg trafiken tog.
Den logg du kan bygga är en lokal fil med en publik adress och en UTC-tidsstämpel per rad. Den är mindre, fulare och mycket mer användbar, eftersom den beskriver just det en utomstående också kan se.
Alternativ A: fånga utgångsadressen själv
En ekkotjänst returnerar vilken källadress förfrågan kom från, och det är per definition utgångsadressen. Kör fångsten efter att tunneln rapporterar ansluten, för en klient som säger ansluten innan rutter och DNS har satt sig loggar adressen före tunneln och förgiftar loggen från första raden.
#!/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"Två detaljer gör den där snutten användbar i stället för dekorativ. Tidsstämpel och adress delar en rad, så en senare tolkning slipper para ihop poster, och umask 077 håller filen privat från det att den skapas. Kör den en gång per anslutning i stället för en gång per start, och håll en fil per enhet.
Loggen registrerar när du använde en tunnel och vilket nätverk du syntes från, vilket ligger närmare webbhistorik än en räknare. Välj en lagringstid du kan försvara, håll filen utanför delade synkmappar och rensa den medvetet.
Alternativ B: be leverantören om en historik
Vissa leverantörer för anslutningsloggar och svarar på en supportfråga med en tidsstämpel och ett servernamn. Den loggen beskriver deras infrastruktur och inte din trafik, och den är bara så bra som deras lagringsfönster och deras vilja att titta. Den beskriver dessutom en session, inte en förfrågan. Fönstret är oftast kort, och det mäts från leverantörens sida av tunneln.
Leverantörer som annonserar att de inte loggar kan inte ta fram detta på begäran, och en klientsidig lista över senaste platser är inte samma sak. Att be en leverantör utan loggning om en utgångsadress slutar oftast med en förklaring till varför uppgifterna inte finns.
Vad varje logg kan bevisa i ett supportärende
De två loggarna svarar på olika frågor, och i tabellen slutar jämförelsen vara akademisk.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
Bara den första kolumnen ligger i din hand. En leverantörslogg kan bekräfta att ett konto var anslutet vid en viss tidpunkt, men den kan inte bekräfta vilka förfrågningar som använde tunneln, och den kommer inte att namnge en adress som leverantören behandlar som driftdetalj. Ingen av loggarna identifierar en person, eftersom en delad utgångsadress kan bära många kunder samma minut.
Jämför båda mot en baslinje innan du litar på någon
En adress i sig bevisar ingenting. Fånga den direkta adressen före anslutning, den tunnlade adressen efter, och jämför dem. Identiska värden betyder att tunneln inte bär den förfrågan, vare sig det beror på en delad tunnel, en överordnad proxy eller en klient som föll tillbaka på en direkt väg.
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.1Upprepa jämförelsen för DNS och för IPv6, eftersom ett adresseko bevisar vägen för en enda HTTP-förfrågan och ingenting om vilken resolver som svarade. En enhet som läcker på någon av dem kan se helt frisk ut på den andra.