Kako zabeležiti in preveriti uporabljeni izhodni naslov VPN
Odjemalske aplikacije prikažejo ime lokacije, ne naslova, s katerega je odšel vaš promet. Zajemite izhodni IP ob povezavi in ga primerjajte z neposredno referenco.
Vprašajte namiznega odjemalca VPN, katere strežnike ste uporabili, in pošten odgovor je običajno ime lokacije. To ime je vstopna točka, ki ste jo izbrali, in naslov, s katerega je odšel vaš promet, je lahko povsem drug stroj. Nič v aplikaciji ni zasnovano tako, da bi obdržalo drugo številko, zato je treba zapis zgraditi v trenutku uporabe. Obstajata dva pristopa in le eden od njiju preživi stik s podpornim primerom.
Dva zapisa, od katerih obstaja le eden
Pogled samega odjemalca je v najboljšem primeru seznam izbranih lokacij s časovnimi žigi. To je oblikovalska odločitev in ne spregled: naslovi so obratovalna podrobnost, krožijo med dodelitvami, razkritje preslikave pa oteži tako podporo kot obravnavo zlorab. Ponudniki pred svoja omrežja postavljajo oblake primerke prav zato, da se lahko končna točka premakne, ne da bi komu povedali. Kar vam aplikacija pokaže, je vaša izbira, ne pot, ki jo je promet ubral.
Zapis, ki ga lahko zgradite, je krajevna datoteka z enim javnim naslovom in enim časovnim žigom UTC na vrstico. Je manjši, grši in veliko bolj uporaben, ker opisuje natanko tisto, kar lahko vidi tudi zunanji opazovalec.
Možnost A: izhodni naslov zajemite sami
Odmevna storitev vrne izvorni naslov, s katerega je zahteva prispela, kar je po definiciji izhodni naslov. Zajem zaženite potem, ko tunel sporoči povezavo, ker bo odjemalec, ki reče povezano, preden se utrdijo poti in DNS, zabeležil naslov pred tunelom in zastrupil dnevnik že od prve vrstice.
#!/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"
Dve podrobnosti naredita ta odlomek uporaben in ne okrasen. Časovni žig in naslov si delita eno vrstico, tako da kasnejša obdelava ne mora pariti zapisov, in umask 077 ohrani datoteko zasebno od trenutka nastanka. Zaženite ga enkrat na povezavo in ne enkrat na zagon ter imejte eno datoteko na napravo.
Dnevnik beleži, kdaj ste uporabili tunel in iz katerega omrežja ste se pojavili, kar je bližje zgodovini brskanja kot števcu. Izberite obdobje hrambe, ki ga lahko zagovarjate, hranite datoteko zunaj skupnih map za sinhronizacijo in jo namerno počistite.
Možnost B: ponudnika prosite za zgodovino
Nekateri ponudniki vodijo dnevnike povezav in bodo na podporno vprašanje odgovorili s časovnim žigom in imenom strežnika. Ta zapis opisuje njihovo infrastrukturo in ne vašega prometa ter velja le toliko, kolikor veljata njihovo okno hrambe in njihova pripravljenost pogledati. Opisuje tudi sejo in ne zahteve. Okno je običajno kratko in meri se s ponudnikove strani tunela.
Ponudniki, ki oglašujejo, da ne beležijo, tega na zahtevo ne morejo pripraviti, seznam nedavnih lokacij na strani odjemalca pa ni isto. Prositi ponudnika brez dnevnikov za izhodni naslov se običajno konča z razlago, zakaj teh podatkov ni.
Kaj lahko vsak zapis dokaže v podpornem primeru
Zapisa odgovarjata na različna vprašanja in prav v preglednici primerjava neha biti akademska.
| 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 |
Samo prvi stolpec je pod vašim nadzorom. Ponudnikov zapis lahko potrdi, da je bil račun ob določenem času povezan, ne more pa potrditi, katere zahteve so uporabile tunel, in ne bo navedel naslova, ki ga ponudnik obravnava kot obratovalno podrobnost. Noben zapis ne identificira osebe, ker lahko skupni izhodni naslov v isti minuti nosi veliko strank.
Primerjajte oba z referenco, preden zaupate kateremu koli
Naslov sam po sebi ne dokaže ničesar. Zajemite neposredni naslov pred povezavo, tunelirani naslov za njo in ju primerjajte. Enake vrednosti pomenijo, da tunel te zahteve ne prenaša, bodisi zaradi razdeljenega tunela, nadrejenega proxyja ali odjemalca, ki je padel nazaj na neposredno pot.
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
Ponovite primerjavo za DNS in za IPv6, ker odmev naslova dokaže pot ene same zahteve HTTP in nič o tem, kateri resolver je odgovoril. Naprava, ki pušča pri enem od obeh, je lahko pri drugem videti popolnoma zdrava.