Que salto NAT perde o mapeado VPN inactivo e como sabelo
Un fluxo VPN inactivo pode morrer en calquera salto con estado. Repita unha proba, compare o que viu cada fronteira e informe do resultado acoutado en lugar dun culpable suposto.
Tras un período de calma o túnel reconéctase, ningún rexistro nomea un culpable, e o movemento obvio é escoller o dispositivo coa documentación de tempo de espera máis impresionante. Iso é unha conxectura vestida de diagnóstico. O estado pode sobrevivir un anaco nun router doméstico, nun tradutor do operador e nun bordo de nube, e calquera deles pode soltar un fluxo que queda calado. O que si pode facer é mapear a ruta, marcar que dispositivos pode observar de verdade e executar unha proba de inactividade que poida repetir.
Unha proba repetible converte unha anécdota nunha medición. Todo o que segue supón un cliente, un servidor e un protocolo, e supón que se resiste a cambiar dúas variables á vez. A idea é facer que a próxima ocorrencia saia máis barata ca esta.
Execute a mesma proba de inactividade cada vez
Anote cando estivo ben o fluxo por última vez, canto tempo permaneceu inactivo despois e se un só paquete novo o recuperou. Eses tres feitos son a medición; sen eles ten unha historia sobre un portátil que caeu. Use o mesmo cliente, o mesmo servidor e o mesmo protocolo en cada repetición, e anote o momento en que se enviou o primeiro paquete tras o silencio.
Despois compare o que viu realmente cada fronteira que posúe. A distinción que decide a investigación é se o servidor non viu nada de ningún tipo tras a pausa, ou se viu a petición e respondeu cara a unha ruta que xa non levaba as respostas.
| 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 |
Comparar rutas sen cambiar cinco cousas
Unha segunda rede de acceso aprobada é unha comparación lexítima, porque a cadea NAT é distinta. Tamén difire en provedor, condicións de radio e quizais familia de enderezos, así que o resultado é unha fronteira e non unha atribución. Rexiste as limitacións xunto co resultado en lugar de deixalas caer en silencio cando informe. Anote a ruta de paso: dispositivo, papel e se o seu estado se pode ler.
O que compra unha comparación de rutas é unha pregunta acoutada: o fluxo sobrevive nunha e morre na outra tras un silencio similar, así que a variable vive nalgún punto das partes que difiren. É un resultado real aínda que non se nomee ningún dispositivo, e di ao seguinte enxeñeiro onde gastar unha tarde e onde non.
Paga a pena ler o estado local antes de especular sobre os operadores. Nunha pasarela Linux, conntrack -L lista os fluxos rastrexados coa súa vida restante, o que converte unha conxectura sobre un temporizador nun número que pode ver expirar. Léao antes e despois do período de inactividade, non só despois.
Que sosterá un sinal de mantemento e que non
Un sinal de mantemento soportado mantén un mapeado aberto, e manter un mapeado aberto non demostra nada sobre o servizo que hai detrás. O túnel pode seguir mapeado mentres a aplicación que transporta deixou de responder, e desde unha luz de estado esas dúas situacións ven iguais. Trate o sinal de mantemento como un seguro contra o vencemento por inactividade, non como unha comprobación de saúde.
Fixe o intervalo contra o tempo de espera máis curto que medise de verdade, non contra un número copiado dun foro. Un sinal de mantemento axustado por baixo de calquera temporizador plausible é tráfico que ninguén necesitaba, e ademais elimina o síntoma que lle diría que fronteira vence primeiro. Escolla o intervalo a partir do número medido e deixe todo o demais en paz.
Un cambio, e logo mida outra vez
Resista o impulso de subir todos os tempos de espera e baleirar todas as pasarelas durante unha proba en vivo. Iso borra a evidencia pola que veu e interrompe fluxos doutras persoas, o que é un mal intercambio por unha hipótese que non probou. Cambie un axuste soportado nun só dispositivo, e logo repita o período de inactividade e a recuperación da aplicación.
Anote que observación de fronteira se moveu, e anóteo mesmo cando nada mellorou. Un axuste que non arranxou nada é información, e é máis barato notalo unha vez que estendelo por toda a instalación.
Escribir un achado que poida defender
Cando non se pode inspeccionar un tradutor augas arriba, diga só o que a evidencia sostén: o intercambio morre nalgún punto deste treito da ruta tras ese tanto de calma, e o salto responsable queda sen atribuír. Unha afirmación acoutada sobrevive á revisión e apunta a seguinte persoa ao segmento correcto. Nomear un router oculto como causa non fai nin unha cousa nin a outra. Entregue o achado acoutado a quen posúa o segmento non observable, co intervalo anexo.
RFC 4787 describe por que os temporizadores de mapeado UDP son difíciles de inferir desde un extremo, e esa dificultade é a razón pola que o achado acoutado é o honesto. Os temporizadores son reais, e tamén o é a incerteza que os rodea.