Korleis registrera og stadfesta VPN-utgangsadressa du brukte
Klientappar viser eit stadnamn, ikkje adressa som trafikken din gjekk ut frå. Registrer utgangs-IP-en ved tilkopling og samanlikn han med ei direkte grunnlinje.
Spør ein skrivebords-VPN-klient kva tenarar du brukte, og det ærlege svaret er oftast eit stadnamn. Det namnet er inngangspunktet du valde, og adressa som trafikken din gjekk ut frå kan vera ein heilt annan maskin. Ingenting i appen er laga for å halda på det andre nummeret, så registeret må byggjast i bruksaugneblinken. Det finst to framgangsmåtar, og berre éin av dei overlever ein støttesak.
To register, og berre eitt av dei finst
Klienten sitt eige oversyn er i beste fall ei liste over valde stader med tidsstempel. Det er eit designval og ikkje ei gløymsle: adresser er driftdetaljar, dei roterer mellom tildelingar, og å leggja samsvaret ope gjer både støtte og handsaming av misbruk vanskelegare. Tilbydarar set skylag framfor netverka sine nettopp for at endepunktet skal kunna flytta seg utan å seia det til nokon. Det appen viser deg er valet du tok, ikkje ruta trafikken følgde.
Registeret du kan byggja er ei lokal fil med éi offentleg adresse og eitt UTC-tidsstempel per line. Ho er mindre, styggare og mykje nyttigare, fordi ho skildrar nøyaktig det ein utanforståande også kan sjå.
Val A: registrer utgangsadressa sjølv
Ein ekko-teneste returnerer kjeldeadressa som førespurnaden kom frå, og det er per definisjon utgangsadressa. Køyr registeringa etter at tunnelen melder tilkopla, fordi ein klient som seier tilkopla før ruter og DNS har sett seg, vil registrera adressa før tunnelen og forgifta loggen frå fyrste line.
#!/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 detaljar gjer den snutten nyttig og ikkje berre pynt. Tidsstempel og adresse deler éi line, så ein seinare analyse slepp å para postar, og umask 077 held fila privat frå ho vert laga. Køyr han éin gong per tilkopling og ikkje éin gong per oppstart, og hald éi fil per eining.
Loggen registrerer når du brukte ein tunnel og kva nettverk du viste deg frå, noko som ligg nærare nettlesarhistorie enn ein teljar. Vel ein oppbevaringsperiode du kan forsvara, hald fila utanfor delte synkroniseringsmappar og slett henne med vilje.
Val B: be tilbydaren om ei historie
Nokre tilbydarar held tilkoplingsloggar og vil svara på eit støttespørsmål med eit tidsstempel og eit tenarnamn. Den loggen skildrar infrastrukturen deira og ikkje trafikken din, og han er berre så god som oppbevaringsvindauget deira og viljen deira til å sjå etter. Han skildrar òg ein sesjon, ikkje ein førespurnad. Vindauget er oftast kort, og det vert målt frå tilbydaren si side av tunnelen.
Tilbydarar som annonserer at dei ikkje loggar kan ikkje leggja dette fram på førespurnad, og ei klient-side-liste over nylege stader er ikkje det same. Å be ein tilbydar utan loggar om ei utgangsadresse endar oftast med ei forklaring på kvifor desse dataa ikkje finst.
Kva kvart register kan prova i ein støttesak
Dei to registera svarar på ulike spørsmål, og det er i tabellen at samanlikninga sluttar å vera 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 |
Berre den fyrste kolonnen er under din kontroll. Eit register frå tilbydaren kan stadfesta at ein konto var tilkopla på eit gjeve tidspunkt, men det kan ikkje stadfesta kva førespurnader som nytta tunnelen, og det vil ikkje nemna ei adresse som tilbydaren behandlar som driftdetalj. Ingen av registera identifiserer ein person, fordi ei delt utgangsadresse kan bera mange kundar i same minutt.
Samanlikn båe med ei grunnlinje før du litar på nokon av dei
Ei adresse åleine provar ingenting. Registrer den direkte adressa før tilkopling, den tunnele adressa etter, og samanlikn dei. Identiske verdiar tyder på at tunnelen ikkje ber den førespurnaden, anten det skuldast ein delt tunnel, ein overordna proxy eller ein klient som fall tilbake til ein direkte veg.
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
Gjenta samanlikninga for DNS og for IPv6, fordi eit adresseekko provar vegen til éin einaste HTTP-førespurnad og ingenting om kven resolvar som svara. Eining som lekk på den eine kan sjå heilt frisk ut på den andre.