Sådan registrerer og verificerer du den VPN-udgangsadresse, du brugte
Klientapps viser et stednavn, ikke den adresse, din trafik forlod fra. Fang udgangs-IP'en ved forbindelse, og sammenlign den med en direkte baseline.
Spørger du en VPN-klient til skrivebordet, hvilke servere du har brugt, er det ærlige svar som regel et stednavn. Navnet er det indgangspunkt, du valgte, og den adresse, din trafik forlod fra, kan være en helt anden maskine. Intet i appen er designet til at gemme det andet nummer, så loggen skal bygges i det øjeblik, den bruges. Der findes to tilgange, og kun én af dem overlever en supportsag.
To logger, og kun én af dem findes
Klientens eget overblik er i bedste fald en liste over valgte steder med tidsstempler. Det er en designbeslutning og ikke en forglemmelse: adresser er driftsdetaljer, de roterer mellem tildelinger, og at blotlægge koblingen gør både support og håndtering af misbrug sværere. Udbydere sætter cloud-instanser foran deres netværk, netop for at endepunktet kan flytte uden at fortælle nogen det. Det, appen viser dig, er det valg, du traf, ikke den rute, trafikken tog.
Den log, du selv kan bygge, er en lokal fil med én offentlig adresse og ét UTC-tidsstempel pr. linje. Den er mindre, grimmere og langt mere nyttig, fordi den beskriver netop det, en udenforstående også kan se.
Mulighed A: Fang selv udgangsadressen
En ekkotjeneste returnerer den kildeadresse, anmodningen kom fra, og det er per definition udgangsadressen. Kør fangsten, efter at tunnelen melder forbundet, for en klient, der siger forbundet, før ruter og DNS har sat sig, registrerer adressen fra før tunnelen og forgifter loggen fra første linje.
#!/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"To detaljer gør den stump brugbar i stedet for dekorativ. Tidsstempel og adresse deler én linje, så en senere parsing ikke skal parre poster, og umask 077 holder filen privat fra det øjeblik, den oprettes. Kør den én gang pr. forbindelse i stedet for én gang pr. opstart, og hold én fil pr. enhed.
Loggen registrerer, hvornår du brugte en tunnel, og hvilket netværk du fremstod fra, hvilket er tættere på browserhistorik end på en tæller. Vælg en opbevaringsperiode, du kan forsvare, hold filen ude af delte synkroniseringsmapper, og ryd den bevidst op.
Mulighed B: Bed udbyderen om en historik
Nogle udbydere fører forbindelseslogge og svarer på et supportspørgsmål med et tidsstempel og et servernavn. Den log beskriver deres infrastruktur og ikke din trafik, og den er kun så god som deres opbevaringsvindue og deres vilje til at kigge. Den beskriver også en session, ikke en anmodning. Vinduet er som regel kort, og det måles fra udbyderens side af tunnelen.
Udbydere, der reklamerer med ingen logning, kan ikke levere dette på anmodning, og en klientside-liste over seneste steder er ikke det samme. At bede en udbyder uden logning om en udgangsadresse ender som regel med en forklaring på, hvorfor dataene ikke findes.
Hvad hver log kan bevise i en supportsag
De to logger besvarer forskellige spørgsmål, og i tabellen holder sammenligningen op med at være 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 |
Kun den første kolonne er under din kontrol. En udbyderlog kan bekræfte, at en konto var forbundet på et givet tidspunkt, men den kan ikke bekræfte, hvilke anmodninger der brugte tunnelen, og den vil ikke nævne en adresse, som udbyderen behandler som driftsdetalje. Ingen af loggene identificerer en person, fordi en delt udgangsadresse kan bære mange kunder i samme minut.
Sammenlign begge med en baseline, før du stoler på nogen af dem
En adresse alene beviser intet. Fang den direkte adresse før forbindelse, den tunnellerede adresse bagefter, og sammenlign dem. Identiske værdier betyder, at tunnelen ikke bærer den anmodning, hvad enten det skyldes en delt tunnel, en overordnet proxy eller en klient, der faldt tilbage til en direkte vej.
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.1Gentag sammenligningen for DNS og for IPv6, for et adresseekko beviser vejen for én HTTP-anmodning og intet om, hvilken resolver der svarede. En enhed, der lækker på en af dem, kan se helt sund ud på den anden.