Как да запишете и проверите използвания изходен адрес на 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 заявка и нищо за това кой резолвер е отговорил. Устройство, което изтича при едното, може при другото да изглежда напълно здраво.