Який хоп 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 важко вивести з однієї кінцевої точки, і саме ця складність робить обмежений висновок чесним. Таймери реальні, і невизначеність навколо них теж.