Kiel registri kaj kontroli la uzitan VPN-eliran-adreson
Klientaj aplikaĵoj montras loknomon, ne la adreson per kiu via trafiko eliris. Kaptu la eliran IP-on ĉe konekto kaj komparu ĝin kun rekta bazlinio.
Demandu al labortabla VPN-kliento, kiujn servilojn vi uzis, kaj la honesta respondo kutime estas loknomo. Tiu nomo estas la enirpunkto, kiun vi tajpis, kaj la adreso, per kiu via trafiko eliris, povas esti tute alia maŝino. Nenio en la aplikaĵo estas farita por konservi la duan numeron, do la registro devas esti konstruata en la momento de la uzo. Ekzistas du aliroj, kaj nur unu el ili postvivas subtenan kazon.
Du registroj, kaj nur unu el ili ekzistas
La propra vido de la kliento estas maksimume listo de elektitaj lokoj kun tempaj markoj. Tio estas dizajna decido, ne malatento: adresoj estas operacia detalo, ili rotacias inter atribuoj, kaj malkaŝi la mapadon malfaciligas kaj subtenon kaj traktadon de misuzo. Provizantoj metas nubajn instancojn antaŭ siaj retoj ĝuste por ke la finpunkto povu translokiĝi sen sciigi iun ajn. Kion la aplikaĵo montras al vi, estas la elekto, kiun vi faris, ne la vojo, kiun ĝi iris.
La registro, kiun vi povas konstrui, estas loka dosiero enhavanta unu publikan adreson kaj unu UTC-tempan markon po linio. Ĝi estas pli malgranda, pli malbela kaj multe pli utila, ĉar ĝi priskribas ĝuste tion, kion ankaŭ ekstera observanto povas vidi.
Opcio A: kaptu la eliran adreson mem
Eĥa servo redonas la fontan adreson, de kiu la peto alvenis, kio estas laŭdifine la elira adreso. Rulu la kapton post kiam la tunelo raportas konektite, ĉar kliento, kiu diras konektite antaŭ ol itineroj kaj DNS stabiliĝas, registros la antaŭtunelan adreson kaj venenos la protokolon ekde la unua linio.
#!/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"
Du detaloj igas tiun peceton uzebla anstataŭ ornama. Tempa marko kaj adreso dividas unu linion, do pli posta analizo ne devas parigi rikordojn, kaj umask 077 tenas la dosieron privata ekde la momento de kreado. Rulu ĝin unufoje po konekto anstataŭ unufoje po lanĉo, kaj tenu unu dosieron po aparato.
La protokolo notas, kiam vi uzis tunelon kaj el kiu reto vi aperis, kio estas pli proksima al retuma historio ol al nombrilo. Elektu konservan periodon, kiun vi povas defendi, tenu la dosieron ekster kunhavataj sinkronigaj dosierujoj, kaj purigu ĝin intence.
Opcio B: petu historion de la provizanto
Iuj provizantoj tenas konektajn protokolojn kaj respondos al subtena demando per tempa marko kaj servila nomo. Tiu registro priskribas ilian infrastrukturon, ne vian trafikon, kaj ĝi validas nur tiom, kiom ilia konserva fenestro kaj ilia pretemo rigardi. Ĝi ankaŭ priskribas sesion, ne peton. La fenestro kutime estas mallonga, kaj ĝi mezuriĝas de la provizanta flanko de la tunelo.
Provizantoj, kiuj reklamas senprotokolecon, ne povas produkti tion laŭpete, kaj klientflanka listo de lastatempaj lokoj ne estas la sama afero. Peti eliran adreson de senprotokola provizanto kutime finiĝas per klarigo, kial tiuj datumoj ne ekzistas.
Kion ĉiu registro povas pruvi en subtena kazo
La du registroj respondas malsamajn demandojn, kaj en la tabelo la komparo ĉesas esti akademia.
| 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 |
Nur la unua kolumno estas sub via kontrolo. Provizanta registro povas konfirmi, ke konto estis konektita je difinita tempo, sed ĝi ne povas konfirmi, kiuj petoj uzis la tunelon, kaj ĝi ne nomos adreson, kiun la provizanto traktas kiel operacian detalon. Neniu el la du registroj identigas personon, ĉar kunhava elira adreso povas porti multajn klientojn en la sama minuto.
Komparu ambaŭ kun bazlinio antaŭ ol fidi iun el ili
Adreso sola pruvas nenion. Kaptu la rektan adreson antaŭ konekto, la tunelan adreson poste, kaj komparu ilin. Identaj valoroj signifas, ke la tunelo ne portas tiun peton, ĉu pro dividita tunelo, ĉu pro superreganta prokuro, ĉu pro kliento, kiu refalis al rekta vojo.
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
Ripetu la komparon por DNS kaj por IPv6, ĉar eĥo de adreso pruvas la vojon de unu sola HTTP-peto kaj nenion pri tio, kiu solvilo respondis. Aparato, kiu likas ĉe unu el ili, povas aspekti tute sana ĉe la alia.