Hvilket NAT-hopp slipper den inaktive VPN-tilordningen, og hvordan du ser det
En inaktiv VPN-strøm kan dø ved ethvert stateful hopp. Gjenta én test, sammenlign hva hver grense så, og rapporter det avgrensede resultatet i stedet for en gjettet synder.
Etter en rolig periode kobler tunnelen seg til på nytt, ingen logg nevner en synder, og det åpenbare trekket er å velge enheten med den mest imponerende timeout-dokumentasjonen. Det er en gjetning kledd ut som en diagnose. Tilstand kan overleve en stund i en hjemmeruter, i en operatørtranslator og ved en skykant, og enhver av dem kan slippe en strøm som blir stille. Det du i stedet kan gjøre, er å kartlegge ruten, markere hvilke enheter du faktisk kan observere, og kjøre én inaktiv test du kan gjenta.
En gjentakbar test gjør en anekdote om til en måling. Alt nedenfor forutsetter én klient, én server og én protokoll, og det forutsetter at du motsetter deg å endre to variabler samtidig. Poenget er å gjøre neste hendelse billigere enn denne.
Kjør den samme inaktive testen hver gang
Skriv ned når strømmen sist var i orden, hvor lenge den deretter satt inaktiv, og om én fersk pakke brakte den tilbake. Disse tre fakta er målingen; uten dem har du en historie om en laptop som falt. Bruk samme klient, samme server og samme protokoll ved hver gjentakelse, og noter øyeblikket da den første pakken etter stillheten ble sendt.
Sammenlign deretter hva hver grense du eier faktisk så. Det skillet som avgjør undersøkelsen, er om serveren ikke så noe som helst etter pausen, eller så forespørselen og svarte inn i en rute som ikke lenger 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 |
Sammenligne ruter uten å endre fem ting
Et andre godkjent tilgangsnett er en legitim sammenligning, fordi NAT-kjeden er forskjellig. Det skiller seg også i leverandør, radioforhold og kanskje adressefamilie, så resultatet er en grense og ikke en tilskrivning. Noter begrensningene sammen med resultatet i stedet for å utelate dem stille når du rapporterer. Skriv ned ruten mens du er i gang: enhet, rolle, og om tilstanden kan leses i det hele tatt.
Det en sammenligning av ruter kjøper deg, er et avgrenset spørsmål: strømmen overlever på den ene og dør på den andre etter en lignende stillhet, så variabelen bor et sted i delene som er forskjellige. Det er et reelt resultat selv når ingen enhet navngis, og det forteller neste ingeniør hvor en ettermiddag bør brukes og hvor den ikke bør brukes.
Lokal tilstand er verdt å lese før du spekulerer i operatører. På en Linux-gateway viser conntrack -L de sporede strømmene med gjenværende levetid, noe som gjør en gjetning om en timer om til et tall du kan se utløpe. Les den før og etter den inaktive perioden, ikke bare etter.
Hva et livstegn holder, og hva det ikke holder
Et støttet livstegn holder en tilordning åpen, og en åpen tilordning beviser ingenting om tjenesten bak. Tunnelen kan forbli tilordnet mens applikasjonen den bærer har sluttet å svare, og fra en statuslampe ser de to situasjonene like ut. Behandle et livstegn som forsikring mot inaktiv utløp, ikke som en helsesjekk.
Sett intervallet etter den korteste timeouten du faktisk målte, ikke etter et tall kopiert fra et forum. Et livstegn tunet under enhver tenkelig timer er trafikk ingen trengte, og det fjerner også symptomet som ville fortalt deg hvilken grense som utløper først. Velg intervallet ut fra det målte tallet, og la alt annet være.
Én endring, mål så igjen
Motstå trangen til å heve hver timeout og skylle hver gateway under en livetest. Det sletter beviset du kom for og avbryter strømmer som tilhører andre, noe som er en dårlig handel for en hypotese du ikke har testet. Endre én støttet innstilling på én enhet, og gjenta så den inaktive perioden og applikasjonens gjenoppretting.
Noter hvilken grenseobservasjon som flyttet seg, og noter det selv når ingenting ble bedre. En innstilling som ikke rettet noe, er informasjon, og det er billigere å merke det én gang enn å rulle den ut over hele eiendommen.
Å skrive et funn du kan forsvare
Når en translator lenger opp ikke kan inspiseres, si bare det evidensen støtter: utvekslingen dør et sted langs dette stykket av ruten etter så mye stillhet, og det ansvarlige hoppet forblir utildelt. Et avgrenset utsagn overlever gjennomgang og peker neste person mot riktig segment. Å utpeke en skjult ruter som årsak gjør ingen av delene. Gi det avgrensede funnet til den som eier det uobserverbare segmentet, med intervallet vedlagt.
RFC 4787 beskriver hvorfor UDP-tilordningstimere er vanskelige å utlede fra ett endepunkt, og den vanskeligheten er grunnen til at det avgrensede funnet er det ærlige. Timere er virkelige, og usikkerheten rundt dem er det også.