Спільний акаунт VPN: ліміт пристроїв — це не ізоляція клієнтів

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

Що насправді обіцяє дозвіл на з'єднання

Ліміт пристроїв рахує, скільки сесій постачальник прийме на одну підписку. Це комерційний і операційний контроль, а не заява про ідентичність чи ізоляцію. Деякі постачальники видають окремий сертифікат для кожного пристрою в межах одного акаунта; інші повторно використовують одні облікові дані для кожного з'єднання. Різниця виявляється під час відкликання, бо окремі дані дають змогу відрізати один пристрій, а спільні такої можливості не залишають.

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

Перевірте, чи пересилає шлюз між клієнтами

Досяжність між вузлами — рішення на боці сервера. У OpenVPN відповідний перемикач відсутній, якщо його не вказано в конфігурації, але сучасне розвантаження площини даних змінює місце застосування правила.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Конфігурація без цієї директиви залишає трафік між вузлами міжмережевому екрану хоста, який усе ще може його дозволяти. Коли розвантаження активне, тунельним інтерфейсом керує ядро, а не процес у просторі користувача, тому перевіряйте лічильники правил, а не довіряйте файлу. Блокування трафіку, що пересилається між адресами тунелю, ізолює клієнтів, не зачіпаючи їхнього доступу до шлюзу. Підтвердьте це спробою від одного клієнта до сервісу на іншому — як до правила, так і після нього.

Захистіть сесію раніше за вузли

Захист тунелю й доступ між вузлами — різні властивості, і сильний шифр не означає ізоляції. У режимі TLS кожен клієнт виводить власні ключі сесії, тож один клієнт не може читати трафік іншого, навіть коли шлюз його пересилає. Стара схема зі статичним ключем ділить один ключ між усіма, тому повторне використання входу там має значно гірші наслідки. Огляньте налаштований режим, а не маркетингову сторінку, і потім оцініть, чи підходить спільний акаунт для цих даних.

Автентифікація сервісу на кожному хості все ще важлива, бо тунель доводить лише те, що клієнт досяг мережі, а не те, що він має досягти певного демона.

Локальні збої Wi-Fi — не компрометація VPN

Обірване з'єднання доводить, що відмовила локальна ланка, а не те, що хтось зламав тунель. Перешкоди, втрачена оренда DHCP і передача під час роумінгу завершують сесію, не зачіпаючи облікових даних чи шифротексту. Сприймайте відключення як знахідку про доступність і тримайте її окремо від знахідок про конфіденційність і доступ між вузлами. Там, де локальна мережа не викликає довіри, захищайте трафік від краю до краю, а не покладайтеся лише на тунель.

Запишіть чотири відповіді: дозвіл, модель ключів, політика щодо вузлів і залежність від локальної ланки. Цей запис перетворює неясне занепокоєння щодо спільного акаунта на конкретні заходи контролю.