Кой 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 съпоставяне са трудни за извеждане от една крайна точка и точно тази трудност прави ограничената констатация честната. Таймерите са реални, както и несигурността около тях.