Qual salto NAT deixa cair o mapeamento VPN inativo e como saber
Um fluxo VPN inativo pode morrer em qualquer salto com estado. Repita um teste, compare o que cada fronteira viu e relate o resultado delimitado em vez de um culpado suposto.
Depois de um período calmo o túnel reconecta-se, nenhum registro nomeia um culpado, e o movimento óbvio é escolher o dispositivo com a documentação de tempo limite mais impressionante. Isso é um palpite vestido de diagnóstico. O estado pode sobreviver um tempo num router doméstico, num tradutor da operadora e na borda de uma nuvem, e qualquer um deles pode largar um fluxo que se cala. O que pode fazer em vez disso é mapear o caminho, marcar quais dispositivos consegue mesmo observar e executar um teste de inatividade que possa repetir.
Um teste repetível transforma uma anedota numa medição. Tudo o que se segue pressupõe um cliente, um servidor e um protocolo, e pressupõe que resiste a mudar duas variáveis ao mesmo tempo. O objetivo é tornar a próxima ocorrência mais barata do que esta.
Execute o mesmo teste de inatividade todas as vezes
Anote quando o fluxo esteve bom pela última vez, quanto tempo ficou inativo depois e se um único pacote novo o recuperou. Esses três factos são a medição; sem eles tem uma história sobre um portátil que caiu. Use o mesmo cliente, o mesmo servidor e o mesmo protocolo em cada repetição, e anote o momento em que o primeiro pacote após o silêncio foi enviado.
Depois compare o que cada fronteira que possui viu realmente. A distinção que decide a investigação é se o servidor não viu nada de todo após a pausa, ou viu o pedido e respondeu para um caminho que já não transportava 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 caminhos sem mudar cinco coisas
Uma segunda rede de acesso aprovada é uma comparação legítima, porque a cadeia NAT é diferente. Também difere em operadora, condições de rádio e talvez família de endereços, pelo que o resultado é uma fronteira e não uma atribuição. Registe as limitações junto com o resultado em vez de as deixar cair em silêncio ao relatar. Anote também o caminho: dispositivo, papel e se o estado dele pode ser lido.
O que uma comparação de caminhos compra é uma pergunta delimitada: o fluxo sobrevive num e morre no outro após um silêncio semelhante, portanto a variável vive algures nas partes que diferem. É um resultado real mesmo quando nenhum dispositivo é nomeado, e diz ao próximo engenheiro onde gastar uma tarde e onde não.
Vale a pena ler o estado local antes de especular sobre operadoras. Num gateway Linux, conntrack -L lista os fluxos rastreados com a sua vida restante, o que transforma um palpite sobre um temporizador num número que pode ver expirar. Leia-o antes e depois do período de inatividade, não só depois.
O que um sinal de manutenção aguenta e o que não aguenta
Um sinal de manutenção suportado mantém um mapeamento aberto, e manter um mapeamento aberto não prova nada sobre o serviço por trás. O túnel pode permanecer mapeado enquanto a aplicação que transporta deixou de responder, e a partir de uma luz de estado essas duas situações parecem iguais. Trate o sinal de manutenção como seguro contra expiração por inatividade, não como verificação de saúde.
Defina o intervalo pelo tempo limite mais curto que realmente mediu, não por um número copiado de um fórum. Um sinal de manutenção afinado abaixo de qualquer temporizador plausível é tráfego de que ninguém precisava, e também remove o sintoma que lhe teria dito qual fronteira expira primeiro. Escolha o intervalo a partir do número medido e deixe tudo o resto em paz.
Uma mudança, depois meça novamente
Resista ao impulso de subir todos os tempos limite e limpar todos os gateways durante um teste ao vivo. Isso apaga as provas por que veio e interrompe fluxos de outras pessoas, o que é uma má troca por uma hipótese que não testou. Mude uma definição suportada num único dispositivo, e depois repita o período de inatividade e a recuperação da aplicação.
Registe qual observação de fronteira se moveu, e registe-a mesmo quando nada melhorou. Uma definição que não corrigiu nada é informação, e é mais barato notá-lo uma vez do que espalhá-lo por toda a instalação.
Escrever uma conclusão que pode defender
Quando um tradutor a montante não pode ser inspecionado, diga apenas o que as provas sustentam: a troca morre algures ao longo deste trecho do caminho após tanto silêncio, e o salto responsável fica por atribuir. Uma afirmação delimitada sobrevive à revisão e aponta a próxima pessoa para o segmento certo. Nomear um router oculto como causa não faz nem uma nem outra coisa. Entregue a conclusão delimitada a quem possui o segmento não observável, com o intervalo anexado.
RFC 4787 descreve por que os temporizadores de mapeamento UDP são difíceis de inferir a partir de uma só extremidade, e essa dificuldade é a razão pela qual a conclusão delimitada é a honesta. Os temporizadores são reais, e a incerteza à volta deles também.