Какой хоп NAT теряет неактивное сопоставление VPN и как это определить
Неактивный поток VPN может умереть на любом хопе, хранящем состояние. Повторите один тест, сравните, что увидела каждая граница, и сообщите об ограниченном результате вместо предполагаемого виновника.
После тихого периода туннель подключается заново, ни один журнал не называет виновника, и очевидный шаг — выбрать устройство с самой впечатляющей документацией по тайм-ауту. Это догадка, переодетая в диагноз. Состояние может какое-то время жить в домашнем маршрутизаторе, в трансляторе оператора и на облачной границе, и любое из них может сбросить замолчавший поток. Вместо этого можно нанести путь на карту, отметить, какие устройства вы действительно можете наблюдать, и провести один неактивный тест, который можно повторить.
Повторяемый тест превращает анекдот в измерение. Всё ниже предполагает одного клиента, один сервер и один протокол, а также то, что вы удерживаетесь от одновременного изменения двух переменных. Смысл в том, чтобы следующий случай обошёлся дешевле этого.
Каждый раз выполняйте один и тот же неактивный тест
Запишите, когда поток последний раз был в порядке, сколько после этого простоял неактивным и вернул ли его один свежий пакет. Эти три факта и есть измерение; без них у вас есть история о упавшем ноутбуке. При каждом повторе используйте того же клиента, тот же сервер и тот же протокол и отметьте момент, когда был отправлен первый пакет после тишины.
Затем сравните, что на самом деле увидела каждая ваша граница. Расследование решает различие: сервер после паузы не увидел вообще ничего или увидел запрос и ответил в путь, который больше не нёс ответы.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Сравнение путей без изменения пяти вещей
Вторая одобренная сеть доступа — законное сравнение, потому что цепочка NAT отличается. Она отличается также провайдером, радиоусловиями и, возможно, семейством адресов, поэтому результат — это граница, а не приписывание. Записывайте ограничения вместе с результатом, а не тихо отбрасывайте их при отчёте. Заодно запишите путь: устройство, роль и можно ли вообще прочитать его состояние.
Сравнение путей даёт вам ограниченный вопрос: поток выживает на одном и умирает на другом после похожей тишины, значит переменная находится где-то в различающихся частях. Это настоящий результат, даже когда ни одно устройство не названо, и он подсказывает следующему инженеру, где потратить день, а где нет.
Локальное состояние стоит прочитать, прежде чем строить догадки об операторах. На шлюзе Linux conntrack -L перечисляет отслеживаемые потоки с оставшимся временем жизни, что превращает догадку о таймере в число, за которым можно наблюдать до истечения. Читайте его до и после периода простоя, а не только после.
Что удержит сигнал поддержания, а что нет
Поддерживаемый сигнал поддержания держит сопоставление открытым, а открытое сопоставление ничего не доказывает о службе за ним. Туннель может оставаться сопоставленным, пока приложение, которое он несёт, уже перестало отвечать, и с точки зрения индикатора состояния эти две ситуации выглядят одинаково. Относитесь к сигналу поддержания как к страховке от истечения по неактивности, а не как к проверке работоспособности.
Задайте интервал по самому короткому тайм-ауту, который вы действительно измерили, а не по числу, переписанному с форума. Сигнал поддержания, настроенный ниже любого возможного таймера, — это трафик, который никому не был нужен, и он же убирает симптом, который сказал бы, какая граница истекает первой. Выберите интервал из измеренного числа и оставьте всё остальное в покое.
Одно изменение, затем измерьте снова
Сдержите желание поднять все тайм-ауты и очистить все шлюзы во время живого теста. Это стирает доказательства, за которыми вы пришли, и прерывает потоки других людей, что плохая сделка для непроверенной гипотезы. Измените одну поддерживаемую настройку на одном устройстве, затем повторите период простоя и восстановление приложения.
Запишите, какое наблюдение на границе сдвинулось, и запишите это даже тогда, когда ничего не улучшилось. Настройка, которая ничего не исправила, — это информация, и заметить это один раз дешевле, чем прокатить по всему хозяйству.
Как написать вывод, который можно защитить
Когда транслятор выше по пути нельзя обследовать, говорите только то, что подтверждают данные: обмен умирает где-то на этом участке пути после столь долгой тишины, а ответственный хоп остаётся неатрибутированным. Ограниченное утверждение выдерживает проверку и направляет следующего человека на нужный сегмент. Называние скрытого маршрутизатора причиной не делает ни того, ни другого. Передайте ограниченный вывод тому, кто владеет ненаблюдаемым сегментом, приложив интервал.
RFC 4787 описывает, почему таймеры сопоставления UDP трудно вывести с одной оконечной точки, и именно эта трудность делает ограниченный вывод честным. Таймеры реальны, и неопределённость вокруг них тоже.