Один вхід у 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, право профілю або політику сеансів шлюзу. Цей запис робить наступну зміну перевірюваною. Він також не дає тому самому питанню відкриватися знову щоразу, коли хтось помічає другий екран входу. Доступність — не авторизація, і ні те, ні те не є ізоляцією.