Чому за одним і тим самим маршрутизатором підключається лише один клієнт 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. Вибір між ними — рішення про термін служби обладнання, а не про налаштування клієнта.

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

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

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

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