Споделен 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 наем и предаване при роуминг прекратяват сесия, без да засягат идентификационни данни или шифрован текст. Отнасяйте се към прекъсването като констатация за наличност и го дръжте отделно от констатациите за поверителност и достъп между партньорите. Където локалната мрежа не е надеждна, защитавайте трафика от край до край, вместо да разчитате само на тунела.

Запишете четирите отговора: разрешение, модел на ключовете, политика между партньорите и зависимост от локалното звено. Този запис превръща смътното безпокойство за споделен акаунт в конкретни контроли.