Два устройства, один Wi-Fi, разные выходы VPN: что это решает

Два ноутбука за одним домашним роутером могут выходить в интернет через разные выходы VPN, и общий Wi-Fi тут ни при чём. Результат определяется тем, где работает туннель и какая политика выбирает путь для каждого запроса. Обратное убеждение столь же распространено и столь же ошибочно: два устройства с отдельными профилями не создают автоматически два публичных адреса. Обе ошибки происходят из привычки считать один адрес тремя.

Три адреса, и только один из них выходит

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

RFC 3022 проводит различие, которое объясняет большую часть здешней путаницы. Традиционный NAT сопоставляет внутренние адреса публичным, а трансляция портов позволяет многим внутренним адресам одновременно делить один публичный адрес. Домохозяйство с одним публичным адресом и несколькими устройствами — это второй случай, и он почти везде используется по умолчанию.

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

Что делает два выхода действительно разными

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

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

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

Почему отдельные профили — не отдельные выходы

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

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

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

Где разместить разделение

Туннель на роутере охватывает всё домохозяйство, что удобно и даёт ровно один общий выход для каждого устройства за ним. Клиент на каждом устройстве даёт поконтрольное управление, но требует, чтобы каждое устройство было подготовлено и оставалось подготовленным. Роутер с поддержкой политик стоит посередине, выбирает путь для каждого устройства, и работает только если надёжно распознаёт устройства сквозь переподключения и изменения DHCP.

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

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

Проверьте выход, который вы реально получили

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

Запускайте это из терминала внутри политики туннеля, а не с устройства, которое её обходит. Неправильный хост даёт уверенный неправильный ответ.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

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