Abra a janela de estado do cliente e os números parecem tranquilizadores: os bytes sobem, o túnel está conectado. Feche a janela e a aplicação de escritório continua a falhar, o que significa que os contadores responderam a uma pergunta que ninguém fez. Contar bytes numa interface mede o tráfego nesse ponto de observação e nada mais. Vá do número que está a ver para a camada de que ele dá conta, e depois para o resultado que a aplicação realmente lhe deu.

Escolha a interface antes de escolher o número

Comece onde o número é apresentado e leia a etiqueta ao lado. Uma janela de cliente pode mostrar totais de sessão, uma interface de túnel pode mostrar bytes de IP interno e um adaptador físico pode mostrar bytes externos encriptados; três contadores diferentes que por acaso são expressos em bytes. Na linha de comandos, netstat -ibn imprime uma linha por endereço em cada interface, pelo que um túnel pode aparecer várias vezes. Faça corresponder a linha à interface que o cliente realmente possui e confirme-a com a rota que o destino escolhe. Um dispositivo chamado utun pode pertencer à VPN, a outro túnel ou a algo que não lhe interessa.

Não troque por um contador de Wi-Fi só porque é mais fácil de ler. Um ponto de observação diferente responde a uma pergunta diferente.

Tire uma diferença, não um total desde o arranque

Leia a linha, faça um pequeno pedido autorizado e volte a ler a mesma linha. A diferença é a prova, porque um total desde o arranque inclui tudo o que a máquina fez. Mantenha o intervalo curto para que o tráfego de fundo tenha menos oportunidades de o contaminar. Numa máquina ocupada, o nettop pode atribuir o débito a um processo, o que estreita o campo antes de voltar aos contadores de interface.

Aceite que a diferença não é limpa. O correio, as atualizações e as mensagens de manutenção da própria ligação do cliente contribuem todos, por isso trate o número como um limite superior e não como uma medição. Se a aplicação foi a única coisa que fez no intervalo, o limite costuma ser suficientemente apertado para ser útil.

Os contadores internos e externos medem coisas diferentes

O adaptador físico conta os pacotes encriptados, incluindo os seus cabeçalhos externos, enquanto a interface do túnel contabiliza a carga útil que recebe ou entrega. Somar os dois conta duas vezes uma mesma transferência. O overhead, as retransmissões e o encapsulamento também tornam impossível uma igualdade simples.

Dois contadores a mover-se em direções opostas são uma descoberta, não uma contradição. Normalmente significa que o tráfego entrou numa camada e nunca saiu da outra.

Combine o contador com o resultado da aplicação

Um total recebido pode subir por causa da conversa do protocolo enquanto o serviço que queria continua a falhar. Um aumento no envio diz ainda menos: prova que o kernel aceitou um pacote, não que algo respondeu.

Registe o resultado exato ao lado dos contadores: a resolução de nomes falhou, a ligação expirou, o TLS foi rejeitado ou chegou uma resposta HTTP. São quatro falhas diferentes e apenas uma delas diz respeito ao túnel. Se a prova tiver de ir mais longe, o próximo ponto de observação é a gateway ou a fronteira do serviço, onde alguém pode ver se o pedido chegou. Repor as preferências de rede do Mac destrói o estado que estava a medir e não lhe diz nada.

Escreva a nota de que a próxima pessoa precisa

Nome da interface, etiqueta do contador, intervalo, valores antes e depois e o resultado da aplicação. Chega para um colega reproduzir a observação sem repetir a sua tarde. Acrescente a versão do cliente e a versão do macOS, porque a semântica dos contadores pode mudar entre versões.

Salte a captura completa de pacotes e o dump do sistema. Raramente são necessários para explicar que contador local se moveu durante um pedido, e atrasam quem lê o relatório. Se o cliente expõe as suas próprias estatísticas, cite a etiqueta dele à letra em vez de a traduzir para a sua. O objetivo da nota é registar o que foi medido, não discutir o que significa.

Artigos relacionados