VPN подключён, но IP-адрес не изменился: почему

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

Подтвердите, что именно измерил тест

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

Используйте эхо публичного адреса и спрашивайте каждое семейство отдельно, потому что результат теста с двойным стеком скрывает интересный случай:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Запустите оба до и после подключения. Если ответ IPv4 меняется на адрес выхода, а ответ IPv6 нет, у вас не сломанный туннель; одно семейство идёт вне его. Если оба ответа остаются прежними, запрос так и не дошёл до туннеля и остальное здесь применимо.

Профиль может охватывать лишь часть трафика

Профиль с раздельным туннелем — обычный ответ, и это не дефект. OpenVPN отправляет всё через туннель только когда redirect-gateway есть среди переданных опций; без него клиент получает несколько конкретных маршрутов, а ваш маршрут по умолчанию остаётся на физическом канале. В Windows тот же переключатель отображается как «Использовать основной шлюз в удалённой сети» в свойствах IPv4 адаптера, и его снятие — осознанный выбор, переживающий каждое переподключение.

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

Одно семейство адресов всё ещё может идти напрямую

Большинство профилей VPN написаны для IPv4, и многие остаются такими. В сети с двойным стеком туннель берёт 10.8.0.x для IPv4, а физический канал сохраняет глобальный адрес IPv6 и маршрут по умолчанию, поэтому сайт с поддержкой IPv6 достигается напрямую, и сообщаемый им адрес — адрес вашего провайдера. Это утечка при работающем туннеле IPv4, и она невидима для теста, который говорит только на IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Читайте интерфейс в каждом ответе. Если поиск IPv6 называет ваше устройство Ethernet или Wi-Fi, а поиск IPv4 называет туннель, политика для этого семейства отсутствует, а не сломана. Отключение IPv6 на всём устройстве убирает симптом и скрывает решение; лучше исправьте покрытие профиля или отключите семейство только на этом подключении и запишите, какой из двух вариантов вы выбрали.

Второй путь может выиграть поиск

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

Составьте опись, прежде чем что-то менять, командами только для чтения:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

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

Измерьте заново со свежим запросом

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

Держите два результата раздельно. Если адрес меняется, но один сайт всё ещё отказывает вам, туннель работает, а сайт отвергает адрес дата-центра; это другая проблема с другим ответом. Если адрес никогда не меняется, пройдите четыре вопроса по порядку: какой адрес вывел тест, какое это было семейство, какое приложение сделало запрос и какой маршрут прошёл этот запрос. Документация Microsoft о решениях маршрутизации VPN объясняет, как клиент Windows выбирает между туннелем и физическим адаптером, когда у обоих есть маршрут.