Varför din VPN tar längre tid att återhämta sig än avbrottet

Wi-Fi:t kom tillbaka för trettio sekunder sedan och VPN:en är fortfarande nere, så klienten ser trasig ut. Ofta följer den bara sitt eget återförsöksschema, och det schemat vet inte att nätverket just kom tillbaka. Den luckan är hela historien: återhämtningstiden är avbrottet plus all väntan som klienten redan har förbundit sig till. Att sänka varje timer är ett svar, och att förstå vilken timer som spelar roll är det andra.

Tre förhållanden avgör om justeringen hjälper: vilket steg som är långsamt, om felet alls går att upprepa och hur klienten får veta att nätverket är tillbaka.

Tre väntetider som ser ut som en

Slutpunktuppslagning, IKE- eller TLS-förhandling, paketåtersändning och att starta ett nytt försök är separata händelser med separata timers. strongSwan dokumenterar återsändningens backoff för IKE, och OpenVPN har egna återförsökskontroller med en annan semantik. Att kopiera en siffra från den ena till den andra förutsätter att mekanismerna stämmer överens, och det gör de inte. Läs loggsekvensen innan du bestämmer vilket intervall du tittar på.

En tyst minut i loggen är inte nödvändigtvis en fryst process. Det kan vara en exponentiell backoff som gör exakt det den är inställd på.

Vilket steg är egentligen långsamt?

Om loggen visar försök som misslyckas med ett autentiseringsfel hjälper ingen timerändring, eftersom inloggningsuppgifterna är fel. Om inga försök alls görs är klienten inne i sitt väntefönster och schemat är lösningen. Om försök görs och tar timeout är problemet nåbarhet eller en saknad lyssnare, och snabbare återförsök fyller bara loggen. Var och en av dessa tre tillstånd har en annan ägare, och bara ett av dem är ett tidsproblem.

Klassificera felet innan du rör en siffra.

När det hjälper att sänka en timer, och när det inte gör det

Sänk taket för återförsök när den dominerande kostnaden är väntan efter ett kort, frekvent avbrott, som en bärbar dator som flyttar sig mellan åtkomstpunkter. Låt det vara när felen är långa eller sällsynta, eftersom aggressiva återförsök lägger till belastning just i det ögonblick då koncentratorn är minst kapabel att svara. I båda fallen, ändra en parameter, registrera den och mät nästa återhämtning i stället för att anta att den blev bättre.

En mycket låg timeout kopierad till varje profil är det vanliga sluttillståndet för justering utan mätning.

Kontrollera beredskapen innan du skyller på klienten

Klienten kan ofta inte se att nätverket är användbart förrän något försöker. En fångad portal, en DHCP-förnyelse eller en ruttändring kan låta den vänta på ett schema som sattes innan något av detta hände. Titta på operativsystemets nätverksstatusändring och klientens nästa försök på samma klocka, och du ser vems väntan det är. Den snabba versionen är att notera tidsstämpeln för nätverket-klart-händelsen och tidsstämpeln för det första försöket efteråt.

Bekräfta också att direkt trafik fortfarande är blockerad under väntan, eftersom en snabbare återanslutning som läcker trafik inte är en förbättring.

Vad som ska registreras

Skriv ner vilken timer som ändrades, från vilket värde till vilket, och hur återhämtningen såg ut efteråt. Notera också klientversionen, eftersom standardvärden flyttar sig mellan utgåvor och en odokumenterad mycket låg timeout förvirrar nästa person som läser profilen.

Den registreringen gör nästa programvaruuppgradering till en jämförelse i stället för ett experiment.