Як фіксувати й перевіряти використану вихідну адресу 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-запиту й нічого не каже про те, який резолвер відповів. Пристрій, що протікає на одному з них, може виглядати цілком здоровим на іншому.