Как фиксировать и проверять использованный выходной адрес VPN
Клиентские приложения показывают название локации, а не адрес, с которого ушёл ваш трафик. Зафиксируйте выходной IP при подключении и сравните его с прямым эталоном.
Спросите настольный VPN-клиент, какими серверами вы пользовались, и честный ответ обычно будет названием локации. Это название — точка входа, которую вы выбрали, а адрес, с которого ушёл ваш трафик, может быть совсем другой машиной. Ничто в приложении не рассчитано на хранение второго числа, поэтому запись приходится создавать в момент использования. Есть два подхода, и только один из них выдерживает проверку обращением в поддержку.
Две записи, и существует только одна из них
Собственный вид клиента — в лучшем случае список выбранных локаций с отметками времени. Это решение проектировщиков, а не упущение: адреса относятся к эксплуатационным деталям, они меняются между назначениями, а раскрытие соответствия усложняет и поддержку, и работу со злоупотреблениями. Провайдеры ставят облачные инстансы перед своими сетями именно для того, чтобы конечная точка могла переехать, никому об этом не сообщая. Приложение показывает вам сделанный выбор, а не маршрут, которым пошёл трафик.
Запись, которую можно построить самостоятельно, — это локальный файл с публичным адресом и отметкой времени UTC в каждой строке. Она меньше, некрасивее и гораздо полезнее, потому что описывает именно то, что может увидеть и сторонний наблюдатель.
Вариант A: зафиксируйте выходной адрес сами
Служба эха возвращает исходный адрес, с которого пришёл запрос, а это по определению и есть выходной адрес. Запускайте фиксацию после того, как туннель сообщит о подключении, потому что клиент, который говорит «подключено» до того, как устоялись маршруты и 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 держит файл закрытым с момента создания. Запускайте его один раз на соединение, а не один раз при загрузке, и держите по одному файлу на устройство.
Журнал отмечает, когда вы пользовались туннелем и из какой сети появились, что ближе к истории просмотров, чем к счётчику. Выберите срок хранения, который сможете обосновать, держите файл вне общих папок синхронизации и удаляйте его осознанно.
Вариант B: запросите историю у провайдера
Некоторые провайдеры ведут журналы соединений и ответят на вопрос поддержки отметкой времени и названием сервера. Такая запись описывает их инфраструктуру, а не ваш трафик, и стоит ровно столько, сколько стоят их окно хранения и их готовность посмотреть. Она также описывает сеанс, а не запрос. Окно обычно короткое, и его отсчитывают со стороны провайдера туннеля.
Провайдеры, которые заявляют об отсутствии журналов, не могут предоставить это по запросу, а список недавних локаций на стороне клиента — не то же самое. Просьба к провайдеру без журналов назвать выходной адрес обычно заканчивается объяснением, почему этих данных не существует.
Что может доказать каждая запись в обращении в поддержку
Две записи отвечают на разные вопросы, и именно в таблице сравнение перестаёт быть академическим.
| 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-запроса и ничего не говорит о том, какой резолвер ответил. Устройство, которое утекает на одном из них, может выглядеть совершенно здоровым на другом.