Kā reģistrēt un pārbaudīt izmantoto VPN izejas adresi
Klientu lietotnes rāda vietas nosaukumu, nevis adresi, no kuras izgāja jūsu trafiks. Uzņemiet izejas IP savienošanās brīdī un salīdziniet to ar tiešu bāzlīniju.
Pajautājiet galddatora VPN klientam, kurus serverus esat izmantojis, un godīgā atbilde parasti būs vietas nosaukums. Šis nosaukums ir ieejas punkts, ko izvēlējāties, un adrese, no kuras izgāja jūsu trafiks, var būt pavisam cita iekārta. Nekas lietotnē nav veidots tā, lai saglabātu otro numuru, tāpēc ieraksts jāveido lietošanas brīdī. Ir divas pieejas, un tikai viena no tām iztur atbalsta lietu.
Divi ieraksti, un pastāv tikai viens no tiem
Paša klienta skats labākajā gadījumā ir izvēlēto vietu saraksts ar laika atzīmēm. Tas ir dizaina lēmums, nevis nokavēšanās: adreses ir ekspluatācijas detaļa, tās rotē starp piešķīrumiem, un atklātā atbilstība apgrūtina gan atbalstu, gan ļaunprātīgas izmantošanas apstrādi. Pakalpojumu sniedzēji liek mākoņa instances savu tīklu priekšā tieši tāpēc, lai galapunkts varētu pārvietoties, nevienam par to nesakot. Tas, ko lietotne rāda, ir jūsu izvēle, nevis maršruts, ko trafiks nogāja.
Ieraksts, ko varat izveidot, ir lokāls fails ar vienu publisku adresi un vienu UTC laika atzīmi katrā rindā. Tas ir mazāks, neglītāks un daudz noderīgāks, jo apraksta tieši to, ko var redzēt arī ārējs novērotājs.
A variants: uzņemiet izejas adresi paši
Atbalss pakalpojums atgriež avota adresi, no kuras atnāca pieprasījums, un tā pēc definīcijas ir izejas adrese. Palaidiet uzņemšanu pēc tam, kad tunelis ziņo savienots, jo klients, kas saka savienots pirms maršrutu un DNS nostabilizēšanās, ierakstīs adresi pirms tuneļa un saindēs žurnālu jau no pirmās rindas.
#!/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"Divi sīkumi padara šo fragmentu lietojamu, nevis dekoratīvu. Laika atzīme un adrese dala vienu rindu, tāpēc vēlākai apstrādei nav jāsapāro ieraksti, un umask 077 tur failu privātu no izveides brīža. Palaidiet to reizi savienojumā, nevis reizi startā, un turiet vienu failu vienā ierīcē.
Žurnāls fiksē, kad izmantojāt tuneli un no kura tīkla parādījāties, kas ir tuvāk pārlūkošanas vēsturei nekā skaitītājam. Izvēlieties glabāšanas termiņu, ko varat aizstāvēt, turiet failu ārpus koplietotām sinhronizācijas mapēm un dzēsiet to apzināti.
B variants: palūdziet pakalpojumu sniedzējam vēsturi
Daži pakalpojumu sniedzēji uztur savienojumu žurnālus un atbildēs uz atbalsta jautājumu ar laika atzīmi un servera nosaukumu. Šis ieraksts apraksta viņu infrastruktūru, nevis jūsu trafiku, un tas ir tik vērtīgs, cik vērtīgi ir viņu glabāšanas logs un viņu vēlme ieskatīties. Tas arī apraksta sesiju, nevis pieprasījumu. Logs parasti ir īss, un to mēra no tuneļa pakalpojumu sniedzēja puses.
Pakalpojumu sniedzēji, kas reklamē, ka neveic žurnālu, nevar to sagatavot pēc pieprasījuma, un klienta puses nesenās vietu saraksts nav tas pats. Lūgt pakalpojumu sniedzējam bez žurnāliem izejas adresi parasti beidzas ar paskaidrojumu, kāpēc šo datu nav.
Ko katrs ieraksts var pierādīt atbalsta lietā
Divi ieraksti atbild uz dažādiem jautājumiem, un tieši tabulā salīdzinājums pārstāj būt akadēmisks.
| 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ūsu kontrolē ir tikai pirmā kolonna. Pakalpojumu sniedzēja ieraksts var apstiprināt, ka konts bija savienots noteiktā laikā, bet nevar apstiprināt, kuri pieprasījumi izmantoja tuneli, un nenorādīs adresi, ko sniedzējs uzskata par ekspluatācijas detaļu. Neviens ieraksts neidentificē personu, jo kopīga izejas adrese vienā minūtē var nest daudz klientu.
Salīdziniet abus ar bāzlīniju, pirms uzticaties kādam no tiem
Adrese pati par sevi neko nepierāda. Uzņemiet tiešo adresi pirms savienošanās, tuneļa adresi pēc tam un salīdziniet tās. Identiskas vērtības nozīmē, ka tunelis nenes šo pieprasījumu, vai nu dalīta tuneļa, pārāka starpniekservera vai klienta, kas atkāpās uz tiešu ceļu, dēļ.
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.1Atkārtojiet salīdzinājumu DNS un IPv6 gadījumā, jo adreses atbalss pierāda viena HTTP pieprasījuma ceļu un neko par to, kurš risinātājs atbildēja. Ierīce, kas noplūst vienā gadījumā, otrā var izskatīties pilnīgi vesela.