Зелёный значок, тот же публичный IP: какой маршрут пропустил VPN

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

Что клиент на самом деле установил

Спросите, какой интерфейс повезёт пакет к реальному адресату, вместо вопроса, поднят ли туннель. Туннель без маршрута к этому адресату — частная дорога, по которой никто не ездит.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

Три вида выборочной маршрутизации

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

Дальняя сторона должна переписать адрес источника

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Назовите интерфейс, который действительно смотрит в интернет, — в современном дистрибутиве это не всегда eth0. Размещённый сервер с постоянным адресом может явно подменять на этот адрес вместо masquerade. Обе половины важны: пересылка без подмены выпускает немаршрутизируемые источники, а подмена без пересылки вообще не видит пакет.

Разрешение имён идёт своим путём

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

resolvectl status | head -20
resolvectl query example.org

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

Четыре наблюдения, которые всё решают

Запишите адрес выхода при выключенном туннеле, затем при включённом. Выполните проверку адресата в обоих состояниях и каждый раз отмечайте интерфейс.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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