Vilket NAT-hopp tappar den inaktiva VPN-mappningen, och hur du ser det
En inaktiv VPN-ström kan dö vid varje tillståndshållande hopp. Upprepa ett test, jämför vad varje gräns såg och rapportera det avgränsade resultatet i stället för en gissad skyldig.
Efter en lugn period återansluter tunneln, ingen logg namnger en skyldig, och det uppenbara draget är att välja enheten med den mest imponerande timeout-dokumentationen. Det är en gissning klädd som en diagnos. Tillstånd kan överleva ett tag i en hemmarouter, i en operatörsöversättare och vid en molnkant, och vilken som helst av dem kan tappa ett flöde som blir tyst. Det du i stället kan göra är att kartlägga vägen, markera vilka enheter du faktiskt kan observera och köra ett inaktivt test som du kan upprepa.
Ett repeterbart test förvandlar en anekdot till en mätning. Allt nedan förutsätter en klient, en server och ett protokoll, och det förutsätter att du avstår från att ändra två variabler samtidigt. Poängen är att göra nästa händelse billigare än den här.
Kör samma inaktiva test varje gång
Skriv ner när flödet senast var i ordning, hur länge det sedan satt inaktivt och om ett färskt paket tog tillbaka det. De tre fakta är mätningen; utan dem har du en historia om en laptop som föll. Använd samma klient, samma server och samma protokoll vid varje upprepning, och notera ögonblicket då det första paketet efter tystnaden skickades.
Jämför sedan vad varje gräns du äger faktiskt såg. Den distinktion som avgör utredningen är om servern inte såg någonting alls efter pausen, eller såg begäran och svarade in i en väg som inte längre bar svaren.
| 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 |
Jämföra vägar utan att ändra fem saker
Ett andra godkänt åtkomstnät är en legitim jämförelse, eftersom NAT-kedjan skiljer sig. Det skiljer sig också i leverantör, radioförhållanden och kanske adressfamilj, så resultatet är en gräns och inte en tillskrivning. Notera begränsningarna tillsammans med resultatet i stället för att tyst utelämna dem när du rapporterar. Skriv ner vägen medan du håller på: enhet, roll och om dess tillstånd alls kan läsas.
Det en jämförelse av vägar köper dig är en avgränsad fråga: flödet överlever på den ena och dör på den andra efter en liknande tystnad, så variabeln bor någonstans i de delar som skiljer sig. Det är ett verkligt resultat även när ingen enhet namnges, och det säger till nästa ingenjör var en eftermiddag ska spenderas och var inte.
Lokalt tillstånd är värt att läsa innan du spekulerar om operatörer. På en Linux-gateway listar conntrack -L de spårade flödena med sin återstående livstid, vilket gör en gissning om en timer till ett tal du kan se löpa ut. Läs den före och efter den inaktiva perioden, inte bara efter.
Vad en keepalive håller och vad den inte håller
En stödd keepalive håller en mappning öppen, och en öppen mappning bevisar ingenting om tjänsten bakom. Tunneln kan förbli mappad medan applikationen den bär har slutat svara, och från en statuslampa ser de två situationerna likadana ut. Behandla en keepalive som försäkring mot inaktiv utgång, inte som en hälsokontroll.
Sätt intervallet efter den kortaste timeout du faktiskt mätte, inte efter ett tal kopierat från ett forum. En keepalive inställd under varje tänkbar timer är trafik ingen behövde, och den tar också bort symptomet som skulle ha sagt vilken gräns som löper ut först. Välj intervallet från det uppmätta talet och låt allt annat vara.
En ändring, mät sedan igen
Motstå lusten att höja varje timeout och spola varje gateway under ett livetest. Det suddar ut bevisen du kom för och avbryter flöden som tillhör andra, vilket är en dålig affär för en hypotes du inte har testat. Ändra en stödd inställning på en enhet, upprepa sedan den inaktiva perioden och applikationens återhämtning.
Notera vilken gränsobservation som flyttades, och notera det även när ingenting blev bättre. En inställning som inte rättade något är information, och det är billigare att märka det en gång än att rulla ut den över hela beståndet.
Att skriva ett fynd du kan försvara
När en översättare längre fram inte kan inspekteras, säg bara det bevisen stöder: utbytet dör någonstans längs det här stycket av vägen efter så mycket tystnad, och hoppet som ansvarar förblir otillskrivet. Ett avgränsat påstående överlever granskning och pekar nästa person mot rätt segment. Att utpeka en dold router som orsak gör ingen av delarna. Lämna det avgränsade fyndet till den som äger det icke observerbara segmentet, med intervallet bifogat.
RFC 4787 beskriver varför UDP-mappningstimers är svåra att härleda från en enda ändpunkt, och just den svårigheten gör det avgränsade fyndet det ärliga. Timers är verkliga, och osäkerheten kring dem också.