Замирание на две секунды: VPN или Wi-Fi?
Двухсекундная остановка и новый сеанс VPN — разные события. Прежде чем менять таймер, разведите путь доступа и туннель по отдельным временным шкалам.
Замирание на две секунды, которое проходит само, выглядит одинаково, независимо от того, туннель ли заново договорился или радио сбилось. Возможно и то, что ничего вообще не падало, и эту возможность стоит проверить первой. Короткий всплеск потерь, повторные переговоры и зависание приложения ощущаются человеком за клавиатурой одинаково. Только один из трёх случаев исправляется изменением конфигурации туннеля.
Две записи, а не одна
Запишите, что произошло с соединением ниже, и отдельно — что сделал сам туннель. Затем сопоставьте паузу приложения с обеими записями. Это независимые ряды событий, которые иногда совпадают, а называть все три обрывом — значит предполагать ответ уже в начале.
Монитор, проверяющий раз в минуту, не может увидеть двухсекундный перерыв. Сообщать, что день был здоровым, технически верно и практически бесполезно. Ставьте интервал выборки рядом с каждым результатом, который цитируете.
Что делал канал доступа, пока приложение замирало
Интервал выборки и тайм-аут определяют, что монитор вообще мог наблюдать, поэтому записывайте оба рядом с результатом. Зафиксированное отсутствие сбоев мало что значит, когда прибор берёт пробу каждые шестьдесят секунд. Затем проверьте три места с отметками времени: локальный маршрутизатор, одобренный внешний хост, достижимый по простому пути, и ресурс за туннелем.
Сначала подтвердите маршруты, потому что публичная цель сама может идти через туннель и тогда измеряет туннель, а не путь доступа. Доказательства, которые действительно датируют сбой, лежат на уровень ниже: события канала на маршрутизаторе, записи ресинхронизации на модеме и изменившийся адрес WAN. Накопительный счётчик ошибок говорит, что что-то пошло не так, но никогда — когда. Соотносите эти записи с окном инцидента, а не читайте их изолированно.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showСчётчик, выросший вчера, ничего не объясняет про замирание сегодня утром. Ограничьте корреляцию окном, о котором сообщил пользователь.
Ищите запись о перезапуске
Потерянная датаграмма UDP сама по себе не заставляет Community OpenVPN начинать новые переговоры TLS. Поведение перезапуска следует ping-restart, и действующее значение могло быть навязано сервером; руководство для 2.6 определяет эти таймеры. Доставка прерывается на мгновение, порог никогда не пересекается, и журнал остаётся пустым. Поэтому ищите в журнале вокруг паузы строку перезапуска, новое подключение или изменившийся идентификатор сеанса. Если ничего из трёх не появилось, туннель, вероятно, ничего не делал, и таймер никогда не был проблемой.
Сокращение каждого keepalive заставляет обнаружение выглядеть быстрее и сдвигает границу, на которой мелкая заминка становится переподключением. Каждое переподключение стоит раунда аутентификации и переустановки маршрутов. Растягивание таймера не покупает ничего, кроме более длинного окна, в котором мёртвый путь всё ещё выглядит живым. И то и другое — решения настройки с ценой, а не бесплатные улучшения.
Отсутствующее событие — тоже доказательство, и именно такое, какое люди пропускают, потому что ничто в журнале не привлекает к нему внимания. Записывайте поиск, который вы выполнили, а не только его результат.
Пусть сравнение решит, что исправлять
Когда обе записи рядом, отнесение обычно пишется само. Событие канала на маршрутизаторе на обоих путях означает, что тема — соединение доступа. Тихий туннель и работающий простой путь означают, что тема — переговоры.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Каждая строка — зацепка, а не приговор: конечные точки снижают приоритет ICMP, и два адресата не обязательно делят один путь. Держите часы клиента, шлюза и приложения согласованными, чтобы сравнение вообще было возможно. Строке, которая подходит к двум столбцам, нужно ещё одно наблюдение, а не решение.
Отчёт, который выдерживает проверку, отвечает на четыре вещи: сколько длилось замирание, какие пути продолжали отвечать, что туннель записал в ту секунду и как часто монитор берёт пробы. Эти четыре факта позволяют следующему читателю воспроизвести наблюдение, а не доверять сводке. Процент доступности скрывает ровно тот интервал, который вас интересует, и фраза "VPN упал" тоже.