Kva NAT-hopp som slepp den inaktive VPN-tilordninga, og korleis du ser det
Ein inaktiv VPN-straum kan døy ved kvar einaste stateful hopp. Gjenta éin test, samanlikn kva kvar grense såg, og rapporter det avgrensa resultatet i staden for ein gissa syndar.
Etter ein roleg periode koplar tunnelen seg til på nytt, ingen logg nemner ein syndar, og det openberre trekket er å velje eininga med den mest imponerande timeout-dokumentasjonen. Det er ei gissing kledd ut som ein diagnose. Tilstand kan overleve ei stund i ein heimeruter, i ein operatørtranslator og ved ein skykant, og kvar av dei kan sleppe ein straum som blir stille. Det du i staden kan gjere, er å kartleggje ruta, markere kva einingar du faktisk kan observere, og køyre éin inaktiv test du kan gjenta.
Ein gjentakbar test gjer ein anekdote om til ei måling. Alt nedanfor føreset éin klient, éin server og éin protokoll, og det føreset at du motset deg å endre to variablar samtidig. Poenget er å gjere neste hending billegare enn denne.
Køyr den same inaktive testen kvar gong
Skriv ned når straumen sist var i orden, kor lenge han deretter sat inaktiv, og om éin fersk pakke brakte han tilbake. Desse tre fakta er målinga; utan dei har du ei historie om ein laptop som fall. Bruk same klient, same server og same protokoll ved kvar gjentaking, og noter augneblinken då den første pakka etter stilla vart send.
Samanlikn deretter kva kvar grense du eig faktisk såg. Det skiljet som avgjer undersøkinga, er om serveren ikkje såg noko som helst etter pausen, eller såg førespurnaden og svara inn i ei rute som ikkje lenger bar svara.
| 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 |
Samanlikne ruter utan å endre fem ting
Eit andre godkjent tilgangsnett er ei legitim samanlikning, fordi NAT-kjeda er ulik. Det skil seg også i leverandør, radiohøve og kanskje adressefamilie, så resultatet er ei grense og ikkje ei tilskriving. Noter avgrensingane saman med resultatet i staden for å utelate dei stille når du rapporterer. Skriv ned ruta medan du er i gang: eining, rolle, og om tilstanden kan lesast i det heile.
Det ei samanlikning av ruter kjøper deg, er eit avgrensa spørsmål: straumen overlever på den eine og døyr på den andre etter ei liknande stillheit, så variabelen bur ein stad i delane som er ulike. Det er eit reelt resultat sjølv når inga eining blir namngitt, og det fortel neste ingeniør kvar ein ettermiddag bør brukast og kvar han ikkje bør brukast.
Lokal tilstand er verdt å lese før du spekulerer i operatørar. På ein Linux-gateway viser conntrack -L dei spora straumane med gjenverande levetid, noko som gjer ei gissing om ein timer om til eit tal du kan sjå gå ut. Les han før og etter den inaktive perioden, ikkje berre etter.
Kva eit livsteikn held, og kva det ikkje held
Eit støtta livsteikn held ei tilordning open, og ei open tilordning beviser ingenting om tenesta bak. Tunnelen kan halde fram med å vere tilordna medan applikasjonen han ber har slutta å svare, og frå ei statuslampe ser dei to situasjonane like ut. Handsam eit livsteikn som forsikring mot inaktiv utløp, ikkje som ein helsesjekk.
Set intervallet etter den kortaste timeouten du faktisk målte, ikkje etter eit tal kopiert frå eit forum. Eit livsteikn tunet under kvar tenkjeleg timer er trafikk ingen trongde, og det fjernar også symptomet som ville fortalt deg kva grense som løp ut først. Vel intervallet ut frå det målte talet, og lat alt anna vere.
Éi endring, mål så igjen
Motstå trangen til å heve kvar timeout og skylje kvar gateway under ein livetest. Det slettar beviset du kom for og avbryt straumar som høyrer til andre, noko som er ein dårleg handel for ein hypotese du ikkje har testa. Endre éi støtta innstilling på éi eining, og gjenta så den inaktive perioden og attopprettinga av applikasjonen.
Noter kva grenseobservasjon som flytta seg, og noter det sjølv når ingenting vart betre. Ei innstilling som ikkje retta noko, er informasjon, og det er billegare å merke det éin gong enn å rulle ho ut over heile eigedomen.
Å skrive eit funn du kan forsvare
Når ein translator lenger opp ikkje kan inspiserast, sei berre det beviset støttar: utvekslinga døyr ein stad langs dette stykket av ruta etter så mykje stillheit, og det ansvarlege hoppet blir ståande utan tilskriving. Ei avgrensa utsegn overlever gjennomgang og peikar neste person mot rett segment. Å peike ut ein skjult ruter som årsak gjer ingen av delane. Gje det avgrensa funnet til den som eig det uobserverbare segmentet, med intervallet vedlagt.
RFC 4787 skildrar kvifor UDP-tilordningstimarar er vanskelege å utleie frå eit endepunkt, og den vansken er grunnen til at det avgrensa funnet er det ærlege. Timerar er verkelege, og usikkerheita rundt dei er det også.