Kaip užfiksuoti ir patikrinti naudotą VPN išėjimo adresą
Klientų programos rodo vietos pavadinimą, o ne adresą, iš kurio išėjo jūsų srautas. Užfiksuokite išėjimo IP jungiantis ir palyginkite jį su tiesiogine baze.
Paklauskite darbalaukio VPN kliento, kuriuos serverius naudojote, ir sąžiningas atsakymas dažniausiai bus vietos pavadinimas. Tas pavadinimas yra įėjimo taškas, kurį pasirinkote, o adresas, iš kurio išėjo jūsų srautas, gali būti visai kita mašina. Niekas programoje nėra sukurta antrajam skaičiui išsaugoti, todėl įrašą reikia sudaryti naudojimo momentu. Yra du būdai, ir tik vienas jų atlaiko susidūrimą su palaikymo byla.
Du įrašai, ir egzistuoja tik vienas jų
Pats kliento vaizdas geriausiu atveju yra pasirinktų vietų sąrašas su laiko žymomis. Tai dizaino sprendimas, o ne apsileidimas: adresai yra eksploatacinė detalė, jie keičiasi tarp priskyrimų, o atskleidus atitikimą tampa sunkiau ir teikti palaikymą, ir tvarkyti piktnaudžiavimą. Tiekėjai stato debesų instancijas prieš savo tinklus būtent tam, kad galinis taškas galėtų persikelti nieko neinformavus. Programa rodo jūsų pasirinkimą, o ne maršrutą, kuriuo srautas ėjo.
Įrašas, kurį galite susikurti, yra vietinis failas su vienu viešu adresu ir viena UTC laiko žyma eilutėje. Jis mažesnis, bjauresnis ir daug naudingesnis, nes apibūdina būtent tai, ką gali pamatyti ir pašalinis stebėtojas.
A variantas: užfiksuokite išėjimo adresą patys
Aido tarnyba grąžina šaltinio adresą, iš kurio atėjo užklausa, o tai pagal apibrėžimą ir yra išėjimo adresas. Paleiskite fiksavimą po to, kai tunelis praneša prisijungęs, nes klientas, kuris sako prisijungęs anksčiau, nei nusistovi maršrutai ir DNS, įrašys adresą prieš tunelį ir užnuodys žurnalą nuo pirmos eilutės.
#!/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"Dvi detalės daro tą ištrauką naudingą, o ne dekoratyvią. Laiko žyma ir adresas dalijasi viena eilute, todėl vėlesniam apdorojimui nereikia poruoti įrašų, o umask 077 saugo failą privatų nuo sukūrimo momento. Paleiskite jį kartą per ryšį, o ne kartą per paleidimą, ir laikykite vieną failą vienam įrenginiui.
Žurnalas fiksuoja, kada naudojote tunelį ir iš kokio tinklo pasirodėte, o tai arčiau naršymo istorijos nei skaitiklio. Pasirinkite saugojimo terminą, kurį galite pagrįsti, laikykite failą ne bendrinamose sinchronizavimo aplankuose ir šalinkite jį sąmoningai.
B variantas: paprašykite tiekėjo istorijos
Kai kurie tiekėjai veda prisijungimų žurnalus ir atsakys į palaikymo klausimą laiko žyma bei serverio pavadinimu. Tas įrašas apibūdina jų infrastruktūrą, o ne jūsų srautą, ir vertas tik tiek, kiek verti jų saugojimo langas ir noras pažiūrėti. Jis taip pat apibūdina sesiją, o ne užklausą. Langas dažniausiai trumpas, ir jis matuojamas iš tiekėjo tunelio pusės.
Tiekėjai, kurie reklamuojasi nieko nevedantys, negali to pateikti paprašius, o kliento pusėje esantis naujausių vietų sąrašas nėra tas pats. Prašymas tiekėjo be žurnalų pateikti išėjimo adresą dažniausiai baigiasi paaiškinimu, kodėl tų duomenų nėra.
Ką kiekvienas įrašas gali įrodyti palaikymo byloje
Du įrašai atsako į skirtingus klausimus, ir būtent lentelėje palyginimas nustoja būti akademinis.
| 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 |
Jūsų kontrolėje yra tik pirmas stulpelis. Tiekėjo įrašas gali patvirtinti, kad paskyra buvo prisijungusi tam tikru metu, bet negali patvirtinti, kurios užklausos naudojo tunelį, ir nepavadins adreso, kurį tiekėjas laiko eksploatacine detale. Nė vienas įrašas neidentifikuoja asmens, nes bendras išėjimo adresas gali nešti daug klientų tą pačią minutę.
Palyginkite abu su baze, prieš pasitikėdami kuriuo nors
Adresas pats savaime nieko neįrodo. Užfiksuokite tiesioginį adresą prieš jungiantis, tunelinį po to ir palyginkite juos. Identiškos reikšmės reiškia, kad tunelis neneša šios užklausos, nesvarbu, ar dėl padalyto tunelio, viršesnio proxy, ar kliento, kuris grįžo prie tiesioginio kelio.
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.1Pakartokite palyginimą DNS ir IPv6 atveju, nes adreso aidas įrodo vienos HTTP užklausos kelią ir nieko apie tai, kuris rezolveris atsakė. Įrenginys, kuris nuteka vienu atveju, kitu gali atrodyti visiškai sveikas.