Slik registrerer og verifiserer du VPN-utgangsadressen du brukte
Klientapper viser et stedsnavn, ikke adressen trafikken din gikk ut fra. Registrer utgangs-IP-en ved tilkobling og sammenlign den med en direkte grunnlinje.
Spør en VPN-klient for skrivebordet hvilke servere du har brukt, og det ærlige svaret er som regel et stedsnavn. Det navnet er inngangspunktet du valgte, og adressen trafikken din gikk ut fra kan være en helt annen maskin. Ingenting i appen er laget for å beholde det andre nummeret, så registreringen må bygges i bruksøyeblikket. Det finnes to fremgangsmåter, og bare én av dem overlever en support-sak.
To registreringer, og bare én av dem finnes
Klientens egen visning er i beste fall en liste over valgte steder med tidsstempler. Det er et designvalg og ikke en forglemmelse: adresser er driftsdetaljer, de roterer mellom tildelinger, og å legge samsvaret åpent gjør både support og håndtering av misbruk vanskeligere. Tilbydere setter skyforekomster foran nettverkene sine nettopp for at endepunktet skal kunne flytte seg uten å si det til noen. Det appen viser deg, er valget du tok, ikke ruten trafikken fulgte.
Registreringen du kan bygge, er en lokal fil med én offentlig adresse og ett UTC-tidsstempel per linje. Den er mindre, styggere og mye nyttigere, fordi den beskriver nøyaktig det en utenforstående også kan se.
Alternativ A: registrer utgangsadressen selv
En ekko-tjeneste returnerer kildeadressen forespørselen kom fra, og det er per definisjon utgangsadressen. Kjør registreringen etter at tunnelen melder tilkoblet, fordi en klient som sier tilkoblet før ruter og DNS har satt seg, vil registrere adressen før tunnelen og forgifte 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 gjør den biten nyttig og ikke bare pynt. Tidsstempel og adresse deler én linje, så en senere analyse slipper å pare poster, og umask 077 holder filen privat fra den opprettes. Kjør den én gang per tilkobling og ikke én gang per oppstart, og hold én fil per enhet.
Loggen registrerer når du brukte en tunnel og hvilket nettverk du dukket opp fra, noe som ligger nærmere nettleserhistorikk enn en teller. Velg en oppbevaringsperiode du kan forsvare, hold filen utenfor delte synkroniseringsmapper og slett den med vilje.
Alternativ B: be tilbyderen om en historikk
Noen tilbydere fører tilkoblingslogger og vil svare på et supportspørsmål med et tidsstempel og et servernavn. Den registreringen beskriver infrastrukturen deres og ikke trafikken din, og den er bare så god som oppbevaringsvinduet deres og viljen deres til å se etter. Den beskriver også en økt, ikke en forespørsel. Vinduet er vanligvis kort, og det måles fra tilbyderens side av tunnelen.
Tilbydere som annonserer at de ikke logger, kan ikke legge dette fram på forespørsel, og en klientside-liste over nylige steder er ikke det samme. Å be en tilbyder uten logger om en utgangsadresse ender vanligvis med en forklaring på hvorfor disse dataene ikke finnes.
Hva hver registrering kan bevise i en support-sak
De to registreringene svarer på ulike spørsmål, og det er i tabellen sammenligningen slutter å 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 |
Bare den første kolonnen er under din kontroll. En tilbyderregistrering kan bekrefte at en konto var tilkoblet på et gitt tidspunkt, men den kan ikke bekrefte hvilke forespørsler som brukte tunnelen, og den vil ikke navngi en adresse tilbyderen behandler som driftsdetalj. Ingen av registreringene identifiserer en person, fordi en delt utgangsadresse kan bære mange kunder i samme minutt.
Sammenlign begge med en grunnlinje før du stoler på noen av dem
En adresse alene beviser ingenting. Registrer den direkte adressen før tilkobling, den tunnelerte adressen etter, og sammenlign dem. Identiske verdier betyr at tunnelen ikke bærer den forespørselen, enten det skyldes en delt tunnel, en overordnet proxy eller en klient som falt tilbake til en direkte rute.
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.1Gjenta sammenligningen for DNS og for IPv6, fordi et adresseekko beviser ruten til én enkelt HTTP-forespørsel og ingenting om hvilken resolver som svarte. En enhet som lekker på den ene, kan se helt frisk ut på den andre.