Общий аккаунт VPN: лимит устройств — это не изоляция клиентов
Разрешение на восемь устройств ничего не говорит об изоляции или управлении ключами. Разделите лимиты аккаунта, защиту туннеля, пересылку между узлами и локальный Wi-Fi.
Восемь одновременных подключений — это число со страницы лицензии, и оно ничего не говорит о том, что эти восемь устройств могут сделать друг с другом. Общий вход может сосуществовать с ключами на каждую сессию, а также со шлюзом, который с удовольствием пересылает трафик одного клиента другому. Ошибка — считать аккаунт границей безопасности. Вместо этого задайте четыре отдельных вопроса: что куплено, что защищает туннель, что может проходить между узлами и что может уронить локальное звено.
Что на самом деле обещает лимит подключений
Лимит устройств считает, сколько сессий провайдер примет на одну подписку. Это коммерческий и операционный контроль, а не заявление о личности или изоляции. Одни провайдеры выдают отдельный сертификат на каждое устройство в рамках одного аккаунта; другие повторно используют одни и те же учётные данные для каждого подключения. Разница проявляется при отзыве, потому что отдельные учётные данные позволяют отрезать одно устройство, а общие такой возможности не оставляют.
Прочитайте, как провайдер выдаёт учётные данные, прежде чем предполагать что-либо о разделении ключей. Само имя аккаунта об этом ничего не говорит.
Проверьте, пересылает ли шлюз трафик между клиентами
Достижимость между узлами — решение на стороне сервера. В OpenVPN соответствующий переключатель отсутствует, если он не указан в конфигурации, но современная разгрузка плоскости данных меняет место применения правила.
grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROPКонфигурация без этой директивы оставляет трафик между узлами межсетевому экрану хоста, который всё ещё может его разрешать. Когда разгрузка активна, туннельным интерфейсом управляет ядро, а не процесс в пользовательском пространстве, поэтому проверяйте счётчики правил, а не доверяйте файлу. Блокировка пересылаемого трафика между адресами туннеля изолирует клиентов, не затрагивая их доступ к шлюзу. Подтвердите это пробой от одного клиента к сервису на другом — как до правила, так и после него.
Защитите сессию раньше узлов
Защита туннеля и доступ между узлами — разные свойства, и сильный шифр не означает изоляции. В режиме TLS каждый клиент выводит собственные ключи сессии, поэтому один клиент не может читать трафик другого, даже когда шлюз его пересылает. Старая схема со статическим ключом делит один ключ между всеми, поэтому повторное использование входа там имеет куда худшие последствия. Изучите настроенный режим, а не маркетинговую страницу, и затем оцените, подходит ли общий аккаунт для этих данных.
Аутентификация сервиса на каждом хосте по-прежнему важна, потому что туннель доказывает лишь то, что клиент достиг сети, а не то, что он должен достичь определённого демона.
Локальные сбои Wi-Fi — не компрометация VPN
Оборванное соединение доказывает, что отказало локальное звено, а не то, что кто-то взломал туннель. Помехи, потерянная аренда DHCP и передача при роуминге завершают сессию, не затрагивая учётные данные или шифртекст. Рассматривайте отключение как находку о доступности и держите её отдельно от находок о конфиденциальности и доступе между узлами. Там, где локальная сеть не заслуживает доверия, защищайте трафик от конца до конца, а не полагайтесь только на туннель.
Запишите четыре ответа: лимит, модель ключей, политика для узлов и зависимость от локального звена. Эта запись превращает смутное беспокойство об общем аккаунте в конкретные меры контроля.