Hvilket NAT-hop taber den inaktive VPN-mapping, og hvordan du ser det
En inaktiv VPN-strøm kan dø ved ethvert stateful hop. Gentag én test, sammenlign hvad hver grænse så, og rapportér det afgrænsede resultat i stedet for en gættet synder.
Efter en rolig periode genopretter tunnelen forbindelsen, ingen log nævner en synder, og det oplagte træk er at vælge den enhed med den mest imponerende timeout-dokumentation. Det er et gæt klædt ud som en diagnose. Tilstand kan overleve et stykke tid i en hjemmerouter, i en operatørtranslator og ved en cloud-kant, og enhver af dem kan tabe en strøm, der bliver tavs. Det, du i stedet kan gøre, er at kortlægge ruten, markere hvilke enheder du faktisk kan observere, og køre én inaktiv test, du kan gentage.
En gentagelig test forvandler en anekdote til en måling. Alt nedenfor forudsætter én klient, én server og én protokol, og det forudsætter, at du modstår at ændre to variabler på én gang. Pointen er at gøre den næste hændelse billigere end denne.
Kør den samme inaktive test hver gang
Skriv ned, hvornår strømmen sidst var god, hvor længe den derefter sad inaktiv, og om én frisk pakke bragte den tilbage. De tre fakta er målingen; uden dem har du en historie om en laptop, der faldt. Brug den samme klient, den samme server og den samme protokol ved hver gentagelse, og notér det øjeblik, hvor den første pakke efter tavsheden blev sendt.
Sammenlign derefter, hvad hver grænse, du ejer, faktisk så. Den sondring, der afgør undersøgelsen, er, om serveren slet ikke så noget efter pausen, eller om den så anmodningen og svarede ind i en rute, der ikke længere bar svarene.
| 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 |
At sammenligne ruter uden at ændre fem ting
Et andet godkendt adgangsnetværk er en legitim sammenligning, fordi NAT-kæden er forskellig. Det adskiller sig også i udbyder, radioforhold og muligvis adressefamilie, så resultatet er en grænse og ikke en tilskrivning. Notér begrænsningerne sammen med resultatet i stedet for stille at udelade dem, når du rapporterer. Skriv ruten ned, mens du er i gang: enhed, rolle, og om dens tilstand overhovedet kan læses.
Det, en sammenligning af ruter køber dig, er et afgrænset spørgsmål: strømmen overlever på den ene og dør på den anden efter en lignende tavshed, så variablen bor et sted i de dele, der er forskellige. Det er et reelt resultat, selv når ingen enhed nævnes, og det fortæller den næste ingeniør, hvor en eftermiddag skal bruges, og hvor den ikke skal.
Lokal tilstand er værd at læse, før du spekulerer i operatører. På en Linux-gateway viser conntrack -L de sporede strømme med deres resterende levetid, hvilket gør et gæt om en timer til et tal, du kan se udløbe. Læs den før og efter den inaktive periode, ikke kun efter.
Hvad et vedligeholdelsessignal holder, og hvad det ikke holder
Et understøttet vedligeholdelsessignal holder en mapping åben, og en åben mapping beviser intet om tjenesten bag den. Tunnelen kan forblive mappet, mens applikationen, den bærer, er holdt op med at svare, og fra en statuslampe ser de to situationer ens ud. Behandl et vedligeholdelsessignal som en forsikring mod inaktiv udløb, ikke som et sundhedstjek.
Sæt intervallet efter den korteste timeout, du faktisk har målt, i stedet for et tal kopieret fra et forum. Et vedligeholdelsessignal tunet under enhver tænkelig timer er trafik, ingen havde brug for, og det fjerner også det symptom, der ville have fortalt dig, hvilken grænse der udløber først. Vælg intervallet ud fra det målte tal, og lad alt andet være.
Én ændring, mål så igen
Modstå trangen til at hæve hver timeout og skylle hver gateway under en live test. Det sletter beviset, du kom for, og afbryder strømme, der tilhører andre, hvilket er en dårlig handel for en hypotese, du ikke har testet. Ændr én understøttet indstilling på én enhed, og gentag så den inaktive periode og applikationens genopretning.
Notér, hvilken grænseobservation der flyttede sig, og notér det, selv når intet blev bedre. En indstilling, der ikke rettede noget, er information, og det er billigere at bemærke én gang end at rulle den ud over hele ejendommen.
At skrive en konklusion, du kan forsvare
Når en translator længere oppe ikke kan inspiceres, så sig kun det, evidensen understøtter: udvekslingen dør et sted langs dette stykke af ruten efter så meget tavshed, og det ansvarlige hop forbliver utildelt. Et afgrænset udsagn overlever gennemgang og peger den næste person mod det rigtige segment. At udpege en skjult router som årsag gør ingen af delene. Giv den afgrænsede konklusion til den, der ejer det uobserverbare segment, med intervallet vedlagt.
RFC 4787 beskriver, hvorfor UDP-mapping-timere er svære at udlede fra ét endepunkt, og den vanskelighed er grunden til, at den afgrænsede konklusion er den ærlige. Timere er virkelige, og usikkerheden omkring dem er det også.