IP-адрес выхода VPN не доказывает туннель: что видят серверы

Кто-то просит сервис, до которого могут добраться только пользователи VPN, и очевидная реализация — разрешить список адресов выхода. Список делает нечто реальное: он ограничивает, кто может подключиться. Он не доказывает, что использовался туннель, потому что адрес принадлежит тому, кто управляет выходом, а этот оператор может пересылать чужой трафик. Разрыв между этими утверждениями и есть вся проблема проектирования.

Сервер видит один адрес на соединение

Соединение приходит с адресом источника и портом назначения, и это всё, что сообщает сетевой уровень. Когда клиент использует туннель, пакеты, доходящие до вашего слушателя, приходят с выхода или из трансляции перед ним. Собственный адрес клиента, обычно частный, никогда не появляется. Поэтому правило межсетевого экрана, написанное для диапазона локальной сети клиента, не делает ничего.

Всё после этого адреса источника — данные приложения, и приложение может доверять им лишь настолько, насколько оно их удостоверяет.

Проверьте, как выглядит ваш выход

Посмотрите на путь с обеих сторон, прежде чем писать правило. Взгляд клиента на свой выход и взгляд сервера на соединение — это два факта, которые имеют значение.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Первая команда сообщает публичный адрес, под которым выглядит клиент, и это значение должна содержать любая разрешающая запись. Вторая показывает установленные соединения на сервере с адресами их партнёров, и именно с этим правило будет действительно совпадать. Если оба не согласуются с вашей мысленной моделью, исправьте модель до редактирования политики. Межсетевой экран облачной базы данных, список разрешений приложения и балансировщик нагрузки могут видеть разный слой трансляции.

Перечислить можно только один из двух наборов выходов

Один случай проверяем в момент запроса, а другой нет, что даёт совершенно разные гарантии.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

Опубликованный список выходов Tor можно получить и сравнить, с учётом возраста списка и собственной политики каждого выхода, поэтому правило отказа для известных выходов применимо и проверяемо. Эквивалентного реестра для коммерческих VPN не существует. Адреса меняются, многие провайдеры ничего не публикуют, и туннель может работать на арендованном облачном адресе, который никогда не принадлежал VPN. Список, который вы составляете, — снимок наблюдаемых адресов, а расширение его до диапазонов хостинга добавляет несвязанные нагрузки, не добавляя доказательств.

Используйте адреса как вход политики, а не как доказательство

Решите, для чего нужно правило. Сетевое ограничение должно оставаться узким, записывать наблюдаемый адрес с датой и причиной и давать законным пользователям путь восстановления при изменении их выхода. Контроль доступа нуждается в аутентифицированной учётной записи или подписанном токене, потому что только они связывают запрос с личностью. Оценка риска может использовать адрес как единственный ненадёжный сигнал, принимая его ложные срабатывания и слепые зоны. Написать правило как продуктовое решение честно; написать его как проверку существования туннеля — нет.

Зеркальный запрос, восстановление настоящего адреса пользователя за VPN, терпит неудачу по той же причине: одно соединение несёт один адрес, и изменение между сессиями согласуется с несколькими объяснениями. Относитесь к прежнему значению как к истории, а не как к истине.