Почему за одним и тем же роутером подключается только один клиент VPN

Два ноутбука находятся в одной домашней сети, и офисный VPN принимает ровно один из них. Второй либо уходит в тайм-аут, либо ждёт, пока первый отключится, и никто между двумя попытками не трогал настройку клиента. Учётные данные те же, что работали минуту назад, и это подсказка: аутентификация не является причиной отказа. Такой шаблон создают три механизма, и собственный журнал сервера говорит, с каким вы столкнулись.

Прочитайте журнал шлюза, прежде чем трогать клиента

Запись сервера о двух попытках отвечает на первый вопрос, и отвечает одним из трёх способов. Если вторая попытка никогда не появляется в этом журнале, пакет не дошёл до слушателя, и проблема принадлежит домашнему роутеру или пути провайдера. Если журнал фиксирует попытку и отклоняет её, туннель дошёл, значит речь об учётной записи, лицензии или лимите сеансов, а не о чём-то на проводе. Если журнал фиксирует успешный сеанс, а клиент всё ещё сообщает об ошибке, посмотрите на обратный путь или на то, что двум клиентам выдаётся один и тот же адрес туннеля.

Точка доступа с телефона дёшево разделяет эти семейства: запустите второй клиент через мобильные данные, пока первый остаётся подключённым. Успех там указывает на домашнюю сеть, а тот же отказ там указывает на шлюз, и роутер остаётся невиновным. Ни один результат сам по себе не решает, но каждый за одну попытку убирает половину пространства поиска.

Запишите результат, прежде чем что-либо менять, потому что три исхода журнала ведут к трём несвязанным исправлениям. Заметка, называющая, который из трёх вы видели, ценнее скриншота ошибки клиента.

Что роутер делает с GRE и NAT-T

PPTP — классический виновник: канал управления это TCP 1723, а путь данных — GRE, то есть протокол IP 47. Многие потребительские роутеры поставляются с помощником PPTP, который отслеживает одно управляющее соединение, поэтому второй клиент за тем же NAT открывает свой канал управления и затем вовсе не получает путь данных. Проброс TCP-порта с номером 47 ничего не даёт для GRE, потому что GRE — это номер протокола, а не порт.

L2TP поверх IPsec ведёт себя иначе по замыслу: IKE использует UDP 500, прохождение через NAT переносит защищённую нагрузку на UDP 4500, и инкапсуляция существует именно для того, чтобы несколько клиентов за одним адресом могли дойти до одного шлюза. Этот замысел не мешает шлюзу или промежуточному устройству ввести лимит сеансов на адрес, а с дивана оба отказа выглядят одинаково. Собственный протокол SoftEther имеет тот же класс проблемы: роутер без работающего проброса впускает первого клиента из локальной сети и отбрасывает второго. Проверьте переключатель ALG или проброса на роутере в обоих положениях, потому что помощник, написанный для старого клиента, может испортить пакеты, которые отправляет нынешний.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Лимиты учётных данных, похожие на лимиты транспорта

Роутер не единственный подозреваемый, и журнал отличает его от альтернативы. Когда сервер OpenVPN привязывает общее имя к одному адресу туннеля, оба устройства получают этот адрес, и без duplicate-cn более новый сеанс вытесняет старый. Включение этой опции оставляет оба подключёнными, но оставляет им одну учётную запись, один сертификат и одно решение об отзыве, что хуже, чем кажется. Второе устройство тогда никогда нельзя отозвать отдельно, поэтому переключатель удобства тихо убирает контроль, который может понадобиться позже.

Читайте журнал сервера и файл состояния вместе, потому что один показывает решение об аутентификации, а другой — кто подключён сейчас. Две записи с одним общим именем и одним виртуальным адресом подтверждают столкновение учётных данных, а не лимит роутера. Коммерческие шлюзы добавляют свои лимиты, например тариф с одной одновременной сессией, количество лицензий или правило, разрешающее одну сессию на публичный адрес, и ни одна настройка роутера ничего из этого не меняет.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Сопоставьте исправление с записью в журнале

Отказ в журнале требует отдельных учётных данных для каждого устройства, более высокого лимита от того, кто ведёт сервис, или второй конечной точки шлюза для одной машины. Если ни одна вторая попытка никогда не доходит до сервера, долговечное исправление — роутер, который пробрасывает протокол и держит больше одного сеанса, либо транспорт, с которым роутер хорошо справляется, например один поток TCP или UDP. Выбор между ними — решение о сроке службы оборудования, а не о настройках клиента.

Не копируйте профиль работающего устройства на вторую машину и не считайте дело закрытым. Это превращает проблему подключения в проблему контроля доступа, потому что потерянный ноутбук больше нельзя отличить от копии, которая ещё используется. Это также скрывает исходную неисправность, которая возвращается в тот момент, когда появляется третье устройство.

Проверка двух живых сеансов

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

Если оба сеанса выживают и несут трафик, исправление держится, и заметка, написанная в начале, становится записью о том, что было не так. Если выживает только один, вернитесь к первому шагу и проверьте, какой из трёх исходов журнала у вас теперь, потому что ответ мог измениться. Помощники роутера могут маскировать проблему, которая возвращается в другой сети, тогда как лимит на адрес следует за пользователем, а не за устройством. Проверка из второй сети — самый дешёвый способ узнать, что именно вы действительно исправили.