Per què la teva VPN triga més a recuperar-se que la caiguda

El Wi-Fi ha tornat fa trenta segons i la VPN encara està caiguda, així que el client sembla espatllat. Sovint segueix la seva pròpia programació de reintents, i aquesta programació no sap que la xarxa acaba de tornar. Aquest interval és tota la història: el temps de recuperació és la caiguda més l’espera que el client ja havia acceptat. Reduir tots els temporitzadors és una resposta, i entendre quin temporitzador importa és l’altra.

Tres condicions decideixen si l’ajustament ajuda: quina etapa és lenta, si la fallada és reintentable, i com s’assabenta el client que la xarxa ha tornat.

Tres esperes que semblen una

La resolució del punt final, la negociació d’IKE o TLS, la retransmissió de paquets i començar un intent nou són esdeveniments separats amb temporitzadors separats. strongSwan documenta l’endarreriment de retransmissió per a IKE, i OpenVPN té els seus propis controls de reintent amb una semàntica diferent. Copiar un número d’un a l’altre assumeix que els mecanismes coincideixen, i no coincideixen. Llegeix la seqüència del registre abans de decidir quin interval estàs mirant.

Un minut de silenci al registre no és necessàriament un procés congelat. Pot ser un endarreriment exponencial fent exactament allò per a què estava configurat.

Quina etapa és realment lenta?

Si el registre mostra intents que fallen amb un error d’autenticació, cap canvi de temporitzador ajuda, perquè la credencial és incorrecta. Si no es fan intents, el client és dins de la seva finestra d’espera i la programació és la solució. Si es fan intents i s’esgota el temps, el problema és l’abastabilitat o un oient absent, i reintentar més ràpid només omple el registre. Cadascun d’aquests tres estats té un propietari diferent, i només un és un problema de temps.

Classifica la fallada abans de tocar cap número.

Quan ajuda reduir un temporitzador i quan no

Baixa el sostre de reintents quan el cost dominant és l’espera després d’una caiguda curta i freqüent, com un portàtil que es mou entre punts d’accés. Deixa’l estar quan les fallades són llargues o rares, perquè reintentar agressivament afegeix càrrega just en el moment en què el concentrador és menys capaç de respondre. En tots dos casos, canvia un paràmetre, registra’l i mesura la propera recuperació en lloc de suposar que ha millorat.

Un temps d’espera molt baix copiat a cada perfil és l’estat final habitual de l’ajustament sense mesura.

Comprova la disponibilitat abans de culpar el client

El client sovint no pot veure que la xarxa és utilitzable fins que alguna cosa ho intenta. Un portal captiu, una renovació de DHCP o un canvi de ruta poden deixar-lo esperant una programació establerta abans que passés res d’això. Observa el canvi d’estat de xarxa del sistema operatiu i el següent intent del client al mateix rellotge, i veuràs de qui és l’espera. La versió ràpida és anotar la marca de temps de l’esdeveniment de xarxa a punt i la marca de temps del primer intent posterior.

Confirma també que el trànsit directe continua bloquejat durant l’espera, perquè una reconnexió més ràpida que filtra trànsit no és una millora.

Què cal registrar

Anota quin temporitzador ha canviat, de quin valor a quin valor, i com va semblar la recuperació després. Anota també la versió del client, perquè els valors per defecte es mouen entre versions i un temps d’espera molt baix no documentat confondrà la propera persona que llegeixi el perfil.

Aquest registre converteix la propera actualització del programari en una comparació en lloc d’un experiment.