O handshake do WireGuard funciona, o serviço não

O handshake completa-se, o cliente mostra um contador de transferência recente e, mesmo assim, um pedido a um serviço no mesmo servidor falha. Esta combinação confunde as pessoas, porque o túnel funciona de forma demonstravel. O que não está demonstrado é a entrega local: o pacote chegou ao host, e o host ainda tem de o aceitar no socket correto e entregá-lo a um processo com permissão para responder. Percorra esses três pontos de controlo pela ordem.

Pare no primeiro que não se verificar, e não acrescente regras para os restantes.

O handshake prova apenas o túnel

O handshake do WireGuard estabelece chaves entre pares e autoriza o tráfego para os intervalos que cada par listou. Não diz nada sobre que processos escutam no servidor, nem sobre se a firewall do host aceita pacotes dirigidos a um dos seus próprios endereços.

É precisamente esta última distinção que mais se ignora: o tráfego para o próprio host é entrada local, enquanto o tráfego que atravessa o host para outro destino é encaminhamento. São tratados por cadeias de firewall diferentes e por definições diferentes. Verificar a cadeia errada custa uma tarde e devolve contadores que parecem inocentes.

Leia o listener e a rota

No cliente, confirme que o endereço do túnel do servidor é encaminhado para o túnel. No servidor, confirme que existe um socket no endereço que o cliente usa e que o processo por trás é o que pretendia.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Um listener em 127.0.0.1 nunca responderá a um pedido dirigido a 10.66.0.1, faça o que fizer a firewall. Um listener no endereço genérico responderá, a menos que uma regra o bloqueie. A lista de sockets resolve, portanto, metade dos casos antes de se examinar qualquer regra. A porta e o endereço juntos decidem se um pedido pode chegar.

Compare o endereço que o cliente usa com o endereço que o servidor possui realmente na interface do túnel. Uma configuração desatualizada de qualquer lado produz um pedido encaminhado corretamente para um par que não tem esse endereço.

Aplique regras para a entrada local, não para o encaminhamento

Se o pacote chegar e o socket existir, a fronteira restante é a política de entrada. Uma regra que permite o encaminhamento não permite a entrega local, e uma regra limitada a uma interface pode não corresponder ao nome da interface do túnel que espera.

Teste com uma única porta permitida para o serviço pretendido em vez de abrir o host. Depois verifique a autorização da própria aplicação: uma lista de permitidos, uma exigência de conta ou uma ligação a um nome de host específico podem rejeitar um pedido que a rede entregou com sucesso.

Mantenha as verificações de certificado. Uma identidade de certificado inesperada é informação sobre que host respondeu, não um obstáculo a contornar. Clicar para passar esconde a única pista que identifica o serviço errado.

Separe as falhas de nome, tamanho e identidade

Um serviço que funciona por endereço mas falha por nome é um problema de DNS, e a correção pertence à configuração do resolver enviada ao cliente, não à firewall. Um serviço que responde a pedidos pequenos mas encrava em respostas maiores aponta para o tamanho do pacote e para a MTU, o que é uma investigação completamente diferente.

Um erro HTTPS que nomeia o host errado significa normalmente que o pedido chegou a outro serviço, muitas vezes porque um proxy ou outro listener ocupa essa porta. Leia o sujeito do certificado e compare-o com o host que queria alcançar. Essa comparação não custa nada e muitas vezes termina a investigação.

Registe qual ponto de controlo falhou: socket, regra de entrada ou política da aplicação. Essa única linha distingue uma falha de rede de uma decisão de autorização. Também impede a pessoa seguinte de abrir portas que nunca foram o problema.