Baixa taxa de transferência da VPN é um problema de entropia? Normalmente não

Taxa de transferência baixa por um túnel e uma máquina travada à espera de números aleatórios produzem experiências muito diferentes, mas são registradas sob a mesma reclamação. Uma aparece como uma pausa antes de qualquer coisa funcionar. A outra aparece como uma conexão que funciona e move dados devagar enquanto você observa. Decidir qual você tem leva dez minutos e economiza uma semana de suposições.

Dois sintomas que parecem iguais

Um serviço que trava após uma inicialização recente, antes de aceitar uma única conexão, está esperando algo. Um túnel que se estabelece rápido e depois transfere a uma fração da taxa esperada é limitado por outra coisa. A palavra criptografia aparece nas duas histórias, por isso elas são fundidas. Separe-as antes de tocar em um arquivo de configuração.

Coloque carimbos de tempo em torno da inicialização, da autenticação, da renegociação de chaves e da própria transferência. Um atraso longo antes de o túnel ficar utilizável não é uma taxa baixa e estável, e tirar a média dos dois em um único número destrói a evidência.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Os dois primeiros comandos colocam o trabalho de inicialização em uma linha do tempo. O terceiro imprime o valor contábil de entropia do kernel, que é útil como um único ponto de dados e inútil como medidor de largura de banda.

Como é realmente uma espera por números aleatórios

Uma solicitação de bytes aleatórios seguros pode bloquear até que o kernel tenha inicializado sua fonte aleatória. Isso importa mais em máquinas virtuais e placas embarcadas pequenas no início da inicialização, quando pouco ruído ambiental foi coletado. Daí não se segue que cada byte criptografado consuma entropia nova.

Geradores modernos são semeados uma vez e depois produzem saída a partir de uma construção determinística, ressemeando conforme seu próprio cronograma. A transferência em massa não esvazia um pool byte a byte, então um valor baixo do pool durante uma transferência lenta não prova nada sobre a causa.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

O primeiro comando mostra se o processo está parado em uma chamada de números aleatórios enquanto você observa. O segundo mostra as mensagens de inicialização do próprio kernel, e é aí que um travamento de inicialização precoce se torna visível.

Anote a versão do kernel e a biblioteca à qual o serviço realmente se liga, porque o comportamento difere entre implementações e entre versões. Um traço obtido após a recuperação geralmente perde a pausa por completo.

Como é realmente uma lentidão sustentada

Um túnel que transfere devagar o tempo todo é limitado pelo caminho de dados. Uma thread saturada, perda de pacotes externos, retransmissões ou filas de socket cheias produzem cada uma esse padrão, e cada uma tem sua própria correção. A porcentagem agregada de CPU esconde uma única thread ocupada, e essa é a leitura errada mais comum. Olhe o tempo por thread antes de olhar a carga total.

Meça nas duas direções com uma base comparável, e observe os contadores da interface em vez do relatório da própria aplicação.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

O primeiro comando mostra o estado de fila e congestionamento de um par. O segundo e o terceiro relatam descartes e retransmissões na pilha e na interface, onde a causa costuma aparecer primeiro.

Escolha a correção para o gargalo que você mediu

Se a evidência aponta para a inicialização precoce, veja o caminho de semeadura suportado pela plataforma, que em uma máquina virtual pode incluir um dispositivo aleatório fornecido pelo host. Uma imagem de semente copiada sem alteração para muitos convidados não substitui uma inicialização independente.

Se a evidência aponta para o caminho de dados, ajuste o que os contadores indicam. Tamanhos de buffer ajudam quando as filas transbordam e não fazem nada quando uma thread está saturada. Instalar um daemon de entropia para elevar um contador não é um reparo de taxa de transferência, e mudar as suposições de semeadura para um gráfico parecer melhor troca uma propriedade de segurança por um número.

Aceite a mudança apenas quando a mesma medição melhorar nas mesmas condições. Um contador maior não é um resultado; uma espera medida mais curta ou uma transferência mais rápida com uma causa identificada é.