VPN постійно відключається? Пройдіть це в такому порядку

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

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

Перший крок: зафіксуйте інтервал і текст помилки

Почніть із власного журналу клієнта, а не з панелі провайдера. На клієнті Linux журнал служби плюс живий стан тунелю покривають більшу частину:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Запишіть позначки часу останнього успішного рукостискання і момент, коли трафік зупинився, а не лише момент, коли значок змінив колір. GUI-клієнт, який повідомляє про відключення постфактум, може повідомляти про стан, якого ядро досягло секундами раніше.

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

Другий крок: змінюйте одну змінну, а не профіль

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

Ноутбук із портом Ethernet дає друге порівняння, яке повністю прибирає Wi-Fi з картини. Якщо тунель тримається на обох варіантах, початкова мережа доступу заслуговує на увагу: роумінг між точками доступу, домашній маршрутизатор із таблицею трансляції, що спливає, або вища ланка, яка скидає довгі потоки.

Запишіть, яку змінну ви змінили. Порівняння зараховується лише тоді, коли все інше залишилося тим самим, і це включає кінцеву точку сервера та пору дня.

Третій крок: зіставте інтервал із рівнем

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

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

Для випадку простою налаштування залежать від протоколу, і важливі обидва кінці. keepalive 10 60 OpenVPN на сервері надсилає пінг кожні 10 секунд і перезапускає з'єднання через 60 секунд без нього; клієнти WireGuard за NAT використовують PersistentKeepalive = 25 у блоці партнера. OpenVPN також переузгоджує канал даних за таймером, reneg-sec, який за замовчуванням становить 3600 секунд у 2.x.

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

Четвертий крок: порівняйте одну підтримувану альтернативу

Якщо оператор публікує і профіль UDP, і профіль TCP, запустіть той самий пристрій і мережу проти іншого. Використовуйте реальний відповідний файл, а не редагуйте транспорт у скопійованому профілі. Стабільний профіль TCP на шляху, де UDP скидається, звужує проблему до цього шляху; він не доводить, що TCP — кращий транспорт усюди.

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

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

Перевірте виправлення і збережіть можливість відкату

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

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

Схожі статті