Kuris NAT šuolis numeta neaktyvų VPN susiejimą ir kaip tai nustatyti
Neaktyvus VPN srautas gali mirti bet kuriame būseną išlaikančiame šuolyje. Pakartokite vieną testą, palyginkite, ką matė kiekviena riba, ir praneškite apie apribotą rezultatą, o ne apie spėjamą kaltininką.
Po tylios pertraukos tunelis vėl prisijungia, joks žurnalas neįvardija kaltininko, o akivaizdus žingsnis yra pasirinkti įrenginį su įspūdingiausia laukimo laiko dokumentacija. Tai spėjimas, apsirengęs diagnozės drabužiu. Būsena gali kurį laiką išsilaikyti namų maršrutizatoriuje, operatoriaus vertėjyje ir debesijos pakraštyje, ir bet kuris jų gali numesti nutilusį srautą. Vietoj to galite nubrėžti kelią, pažymėti, kuriuos įrenginius iš tikrųjų galite stebėti, ir atlikti vieną neaktyvų testą, kurį galite pakartoti.
Pakartojamas testas anekdotą paverčia matavimu. Viskas žemiau daro prielaidą, kad yra vienas klientas, vienas serveris ir vienas protokolas, ir kad priešinatės dviejų kintamųjų keitimui vienu metu. Tikslas – kad kitas atvejis būtų pigesnis už šį.
Kiekvieną kartą atlikite tą patį neaktyvų testą
Užsirašykite, kada srautas paskutinį kartą buvo tvarkingas, kiek po to jis buvo neaktyvus ir ar vienas šviežias paketas jį grąžino. Šie trys faktai ir yra matavimas; be jų turite istoriją apie nukritusį nešiojamąjį kompiuterį. Kiekvieno pakartojimo metu naudokite tą patį klientą, tą patį serverį ir tą patį protokolą, ir pažymėkite momentą, kai po tylos buvo išsiųstas pirmasis paketas.
Tada palyginkite, ką iš tikrųjų matė kiekviena jums priklausanti riba. Tyrimą lemiantis skirtumas yra tai, ar serveris po pauzės nematė nieko, ar matė užklausą ir atsakė į kelią, kuris nebevežė atsakymų.
| 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 |
Kelių palyginimas nekeičiant penkių dalykų
Antras patvirtintas prieigos tinklas yra teisėtas palyginimas, nes NAT grandinė skiriasi. Jis skiriasi ir tiekėju, radijo sąlygomis bei galbūt adresų šeima, todėl rezultatas yra riba, o ne priskyrimas. Fiksuokite apribojimus kartu su rezultatu, o ne tyliai jų atsisakykite pranešdami. Užrašykite ir kelią: įrenginys, vaidmuo ir ar jo būseną apskritai galima perskaityti.
Kelių palyginimas duoda apribotą klausimą: srautas išgyvena viename ir miršta kitame po panašios tylos, taigi kintamasis yra kažkur tuose deluose, kurie skiriasi. Tai realus rezultatas net ir neįvardijus nė vieno įrenginio, ir jis pasako kitam inžinieriui, kur praleisti popietę, o kur ne.
Vietinę būseną verta perskaityti prieš spėliojant apie operatorius. Linux tinklelyje conntrack -L išvardija stebimus srautus su likusiu gyvavimo laiku, o tai spėjimą apie laikmatį paverčia skaičiumi, kurį galite stebėti baigiantis. Skaitykite jį prieš neaktyvų laikotarpį ir po jo, ne tik po.
Ką palaikys gyvybės signalas ir ko ne
Palaikomas gyvybės signalas laiko susiejimą atvirą, o atviro susiejimo laikymas nieko neįrodo apie už jo esančią paslaugą. Tunelis gali likti susietas, kol jį nešantis susietas taikomasis darinys jau nustojo atsakyti, ir iš būsenos lemputės šios dvi situacijos atrodo vienodai. Gyvybės signalą traktuokite kaip draudimą nuo neaktyvaus pasibaigimo, o ne kaip sveikatos patikrą.
Intervalą nustatykite pagal trumpiausią tikrai išmatuotą laukimo laiką, o ne pagal skaičių, nukopijuotą iš forumo. Gyvybės signalas, sureguliuotas žemiau bet kurio įmanomo laikmačio, yra srautas, kurio niekam nereikėjo, ir jis taip pat pašalina simptomą, kuris būtų pasakęs, kuri riba baigiasi pirmoji. Pasirinkite intervalą iš išmatuoto skaičiaus ir palikite visa kita ramybėje.
Vienas pakeitimas, tada matuokite dar kartą
Atsispirkite norui gyvo testo metu pakelti visus laukimo laikus ir išvalyti visus tinklelius. Tai ištrina įrodymus, dėl kurių atėjote, ir pertraukia kitų žmonių srautus, o tai blogas mainas už neišbandytą hipotezę. Pakeiskite vieną palaikomą nustatymą viename įrenginyje, tada pakartokite neaktyvų laikotarpį ir taikomosios programos atsigavimą.
Užfiksuokite, kuri ribos stebėjimas pasislinko, ir užfiksuokite net tada, kai niekas nepagerėjo. Nustatymas, kuris nieko nesutvarkė, yra informacija, ir pigiau tai pastebėti kartą, nei permesti per visą ūkį.
Parašyti išvadą, kurią galite apginti
Kai negalima apžiūrėti aukštesniojo vertėjo, sakykite tik tai, ką remia įrodymai: mainai miršta kažkur šioje kelio atkarpoje po tiek tylos, o atsakingas šuolis lieka nepriskirtas. Apribotas teiginys atlaiko peržiūrą ir nukreipia kitą žmogų į tinkamą segmentą. Paslėpto maršrutizatoriaus įvardijimas priežastimi nedaro nė vieno iš jų. Apribotą išvadą perduokite tam, kas valdo nestebimą segmentą, pridėdami intervalą.
RFC 4787 aprašo, kodėl UDP susiejimo laikmačius sunku išvesti iš vieno galo, ir būtent šis sunkumas daro apribotą išvadą sąžininga. Laikmačiai yra realūs, ir aplink juos esantis neapibrėžtumas taip pat.