O aperto de mão do WireGuard é concluído, mas não volta nenhuma resposta

Os apertos de mão recentes são uma boa notícia e uma afirmação muito menor do que a frase que as pessoas querem escrever. Os pares trocaram mensagens de aperto de mão autenticadas. Um pacote de aplicação ainda tem de chegar ao seu destino interno e voltar.

Essa lacuna entre um plano de controlo saudável e um plano de dados silencioso é todo o assunto aqui. Duas leituras dos mesmos contadores dizem de que lado está.

Um aperto de mão prova chaves, não entrega

O aperto de mão do WireGuard é um acordo de chaves com autenticação. É concluído assim que os pares se conseguem alcançar e têm chaves válidas. O encaminhamento, a política da firewall e o próprio destino são perguntas que o aperto de mão nunca faz.

Assim, um túnel pode estar perfeitamente estabelecido enquanto cada pacote lá dentro é descartado. Um pacote interno mal encaminhado e uma resposta que segue outro caminho parecem iguais do lado do cliente.

Um único endereço interno é todo o teste

Escolha um destino e fique com ele. O endereço de túnel do próprio par é o caso mais fácil, e um anfitrião atrás do par acrescenta exatamente um salto. Alternar entre os dois sem anotar a mudança produz resultados que ninguém consegue comparar.

Depois veja a rota que o cliente escolhe. Uma rota local mais específica pode enviar o pacote para outro lugar antes de o WireGuard ser consultado, e isso acontece sempre que a LAN doméstica se sobrepõe ao intervalo remoto.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Um endereço que se resolve na interface física já respondeu à pergunta. O túnel não descarta nada. O pacote nunca entrou nele.

Os contadores são provas, não um veredicto

wg show relata os bytes enviados e recebidos por par, e os dois números movem-se de forma independente. Faça uma leitura, faça um pedido permitido e depois faça outra leitura no mesmo minuto.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Envios a subir com receções planas é a assinatura de um pedido sem resposta. Não diz se o pedido foi filtrado, se o destino estava em baixo ou se a resposta saiu por outra rota. São três investigações que partilham um sintoma. Separe-as antes de mudar qualquer configuração.

Um número fixo de bytes também não é um limiar de sucesso. Os valores dos contadores seguem o tráfego, e tratar um único número como prova de saúde produz disparates cheios de confiança.

O par verifica ele mesmo o pacote de retorno

O par remoto só aceita um pacote interno quando a origem cai dentro do seu allowedips. Uma rota que exista no emissor não basta. Uma entrada de origem ausente no receptor descarta o tráfego de retorno em silêncio.

As firewalls do anfitrião estão por trás dessa verificação. Uma regra de reencaminhamento que permite a interface do túnel mas não a sub-rede interna aceita o aperto de mão e rejeita o pacote. Do lado do cliente isso parece exatamente um par morto. Um anfitrião com duas interfaces também pode responder da origem errada, e então o par descarta a resposta que nunca esperou.

Mantenha a experiência honesta

Testar um perfil de acesso remoto a partir da mesma rede doméstica que ele deve alcançar exercita um caminho diferente do pretendido. Passe para a rede externa e anote o seu prefixo local, para que as duas execuções possam ser comparadas.

Uma pequena troca bem-sucedida também não exclui todos os problemas de caminho. Pacotes maiores podem falhar onde os pequenos passam, e um filtro que corresponde por tamanho ou protocolo pode comportar-se de forma diferente sob carga.

Mantenha o aperto de mão como a etapa que se sabe funcionar e avance a partir daí. A próxima prova útil é onde um pedido interno para, não um novo conjunto de chaves e outra ronda de suposições.