Пайдаланған VPN шығу мекенжайын қалай тіркеу және тексеру керек
Клиент қолданбалары орын атауын көрсетеді, трафигіңіз шыққан мекенжайды емес. Қосылу кезінде шығу IP-ін түсіріп алып, оны тікелей базалық сызықпен салыстырыңыз.
Жұмыс үстелінің VPN клиентінен қандай серверлерді пайдаланғаныңызды сұраңыз, адал жауап әдетте орын атауы болады. Бұл атау сіз таңдаған кіру нүктесі, ал трафигіңіз шыққан мекенжай мүлдем басқа машина болуы мүмкін. Қолданбада екінші санды сақтауға арналған ештеңе жоқ, сондықтан жазбаны пайдалану сәтінде құру керек. Екі тәсіл бар және олардың тек біреуі қолдау ісімен бетпе-бет келуге төтеп береді.
Екі жазба, бірақ олардың тек біреуі бар
Клиенттің өз көрінісі ең жақсы жағдайда уақыт белгілерімен таңдалған орындардың тізімі. Бұл дизайн шешімі, ұмытшақтық емес: мекенжайлар операциялық деталь, олар тағайындаулар арасында ауысып отырады, ал сәйкестіктің ашылуы қолдауды да, теріс пайдаланумен жұмысты да қиындатады. Провайдерлер өз желілерінің алдына бұлттық даналарды қояды, дәл соңғы нүкте ешкімге хабарламай-ақ орнын ауыстыра алуы үшін. Қолданба сізге жасаған таңдауыңызды көрсетеді, трафиктің жүрген бағытын емес.
Өзіңіз құра алатын жазба — әр жолда бір жария мекенжай мен бір UTC уақыт белгісі бар жергілікті файл. Ол кішірек, үсқынсыз және әлдеқайда пайдалы, өйткені сыртқы бақылаушының да көре алатын нәрсесін дәл сипаттайды.
А нұсқасы: шығу мекенжайын өзіңіз тіркеңіз
Жаңғырық қызметі сұраныс келген бастапқы мекенжайды қайтарады, бұл анықтама бойынша шығу мекенжайы. Тіркеуді туннель қосылды деп хабарлағаннан кейін іске қосыңыз, өйткені маршруттар мен DNS тұрақталмай тұрып қосылды деген клиент туннельге дейінгі мекенжайды жазып, журналды бірінші жолынан уландырады.
#!/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"Екі деталь бұл үзіндіні әшекей емес, жарамды етеді. Уақыт белгісі мен мекенжай бір жолды бөліседі, сондықтан кейінгі талдау жазбаларды жұптауға мәжбүр болмайды, ал umask 077 файлды жасалған сәттен бастап жеке ұстайды. Оны әр қосылу сайын бір рет, ал жүктелу сайын емес іске қосыңыз және әр құрылғыға бір файл ұстаңыз.
Журнал туннельді қашан пайдаланғаныңызды және қай желіден көрінгеніңізді жазады, бұл санағыштан гөрі шолу тарихына жақын. Өзіңіз қорғай алатын сақтау мерзімін таңдаңыз, файлды ортақ синхрондау қалталарынан тыс ұстаңыз және оны әдейі тазалаңыз.
Б нұсқасы: провайдерден тарих сұраңыз
Кейбір провайдерлер қосылым журналдарын жүргізеді және қолдау сұрағына уақыт белгісі мен сервер атауымен жауап береді. Бұл жазба олардың инфрақұрылымын сипаттайды, сіздің трафигіңізді емес, және ол тек олардың сақтау терезесі мен қарауға деген ықыласы құнды болғанша құнды. Ол сондай-ақ сессияны сипаттайды, сұранысты емес. Терезе әдетте қысқа және туннельдің провайдер жағынан өлшенеді.
Журнал жүргізбейтінін жарнамалайтын провайдерлер мұны сұраныс бойынша бере алмайды, ал клиент жағындағы соңғы орындар тізімі бір нәрсе емес. Журналы жоқ провайдерден шығу мекенжайын сұрау әдетте бұл деректердің неліктен жоқ екенін түсіндірумен аяқталады.
Әр жазба қолдау ісінде нені дәлелдей алады
Екі жазба әртүрлі сұрақтарға жауап береді және дәл кестеде салыстыру академиялық болудан қалады.
| 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 |
Тек бірінші баған сіздің бақылауыңызда. Провайдер жазбасы шоттың белгілі бір уақытта қосылғанын растай алады, бірақ қай сұраныстардың туннельді пайдаланғанын растай алмайды және провайдер операциялық деталь деп санайтын мекенжайды атамайды. Ешбір жазба адамды сәйкестендірмейді, өйткені ортақ шығу мекенжайы бір минутта көп клиентті тасымалдауы мүмкін.
Екеуін де базалық сызықпен салыстырыңыз, біреуіне сенбес бұрын
Мекенжай өз бетінше ештеңені дәлелдемейді. Қосылу алдында тікелей мекенжайды, кейін туннельдік мекенжайды тіркеп, оларды салыстырыңыз. Бірдей мәндер туннельдің бұл сұранысты тасымалдамайтынын білдіреді, ол бөлінген туннель, үстем прокси немесе тікелей жолға қайтқан клиент салдарынан болсын.
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Салыстыруды DNS және IPv6 үшін қайталаңыз, өйткені мекенжай жаңғырығы бір HTTP сұранысының жолын дәлелдейді және қай шешуші жауап бергені туралы ештеңе айтпайды. Біреуінде ағатын құрылғы екіншісінде мүлдем сау көрінуі мүмкін.