Один вход в VPN на общем компьютере: кто ещё получает маршрут?
Вход в VPN удостоверяет одного человека; устанавливаемый им маршрут — это другая область. Сравните туннели для всего хоста, для пользователя и для приложения на общем компьютере.
Совместное использование рабочей станции поднимает вопрос, на который ноутбуку одного пользователя никогда не приходится отвечать: после того как один человек удостоверил туннель, кто ещё может им пользоваться? Вход идентифицирует субъект, а установленный маршрут описывает область, и это не один и тот же объект. Между ними находятся операционная система, конфигурация клиента и то, что частная служба требует сама по себе. Сравнение точек принуждения — единственный способ ответить без догадок.
Один вход, несколько областей
Аутентификация отвечает, кого допустили. Маршрут отвечает, какие пакеты могут выйти через туннель. Авторизация отвечает, какая служба примет получившееся соединение, и ни одно из трёх не подразумевает следующее.
Туннель на весь хост — обычное значение по умолчанию, и он делает разрыв очевидным. Маршрут находится в таблице ядра, поэтому любой процесс, использующий эту таблицу, может достичь частной сети, включая тот, что запустил пользователь, никогда не видевший окна VPN. Это не дефект туннеля; это и есть смысл системного маршрута. Частная служба всё равно может отклонить соединение, поэтому доступность и разрешение нуждаются в отдельных ответах.
Запись четырёх вопросов до тестирования не даёт обзору свестись к одному из них.
Где на самом деле проходит граница
Четыре схемы охватывают большинство машин: туннель на весь хост, соединение для пользователя, список разрешённых приложений и отдельное сетевое пространство имён или виртуальная машина.
Каждая ставит точку принуждения в другое место, и различия важнее названий. Соединение для пользователя обеспечивается правами профиля, а не экраном входа рабочего стола. Список разрешённых приложений обеспечивается внутри клиента, который решает, что будет нести. Пространство имён или ВМ обеспечивает на границе интерфейса, поэтому процесс внутри вообще не видит маршрут хоста. Число экранов входа на машине ничего не говорит ни об одном из них.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
Чтение таблицы строка за строкой показывает, что настоящий вопрос не в том, существует ли изоляция, а в том, где она реализована.
Сравните четыре точки принуждения
В Linux таблица маршрутов — первое, что нужно проверить, потому что туннель на весь хост виден там, а пространство имён нет. Запуск поиска от второго пользователя — шаг, который люди пропускают; ответ отличается от полученного от себя самого, и это объясняет отчёт.
Следующие две проверки смотрят на политику, а не на маршрутизацию. Правило брандмауэра, совпадающее с UID, применяется к локально созданному трафику, поэтому может разделить двух пользователей на одном хосте, даже когда оба делят маршрут. Профиль соединения с явным списком прав обеспечивается менеджером сети при активации. Ни одна проверка не требует менять туннель, поэтому их стоит сделать до любого перепроектирования.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuidЕсли второй поиск показывает маршрут туннеля, граница не там, где предполагал проект.
Правила одновременных сеансов — отдельный контроль
Шлюзы часто ограничивают число сеансов, которые может держать одна учётная запись, и этот предел не имеет отношения к локальным пользователям. Он ограничивает учётную запись, поэтому второй человек, вошедший с теми же данными, может завершить туннель первого.
Прочитайте сбой до того, как предполагать локальную проблему изоляции. Предел сеансов даёт отключение на шлюзе, тогда как проблема области даёт работающий туннель, который просто не несёт трафик другого пользователя. Эти два симптома ведут к совершенно разным исправлениям. Сохраняйте точное сообщение клиента, поскольку в нём обычно названо правило. Попросите владельца профиля об утверждённом порядке работы вместо обхода предела.
Виртуальная машина никого не освобождает от этого правила и добавляет собственный дизайн сети и учётных данных.
Проверяйте тот контекст, который вам важен
Проверьте предполагаемого пользователя и приложение, затем проверьте контекст, который должен быть отклонён. Обзор, который лишь доказывает, что исходный пароль работает, проверил аутентификацию и ничего больше.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'Запишите точку принуждения рядом с каждым результатом: таблицу маршрутов, правило UID, право профиля или политику сеансов шлюза. Эта запись делает следующее изменение проверяемым. Она также не даёт одному и тому же вопросу открываться заново каждый раз, когда кто-то замечает второй экран входа. Доступность — не авторизация, и ни то ни другое не является изоляцией.