Leia uma configuração do WireGuard linha por linha, de Interface a Peer

A maioria das configurações do WireGuard quebradas não erra num valor; coloca o valor certo do lado errado. Uma chave privada pertence a esta máquina, um peer carrega a chave pública da outra máquina, e um endereço fica no bloco interface embora descreva onde o túnel vive. Leia o ficheiro como duas direções que se encontram e depois verifique o que o script auxiliar acrescentou por cima. O protocolo em si tem menos campos do que o ficheiro, e os extra vale a pena conhecê-los em separado.

As chaves de interface descrevem esta máquina

O bloco interface guarda a identidade própria desta extremidade. PrivateKey é essa identidade e nunca sai do anfitrião; a chave pública correspondente é derivada dela e é o que os outros peers listam. ListenPort é onde este lado recebe os handshakes, por isso dois clientes atrás de um mesmo endereço precisam de portas diferentes.

Address é o endereço do túnel a que este anfitrião responde, escrito com um comprimento de prefixo porque também é a origem que vai usar. Errar o prefixo aqui muda quais destinos o anfitrião considera ligados diretamente, e isso produz falhas que parecem de encaminhamento e não de configuração.

Todo o resto num [Interface] bloco com um cliente real costuma ser acrescentado pelo wg-quick: DNS, MTU, Table, e as linhas de gancho. Não são campos do protocolo, e uma instalação wg nua ignora-as por completo.

Cada entrada peer descreve um outro lado

Um [Peer] bloco é a parte remota. PublicKey é a chave derivada dessa parte, nunca a sua chave privada, e PresharedKey é um segredo extra opcional que ambos os lados devem ter idêntico. Endpoint é para onde enviar, e PersistentKeepalive pede a este anfitrião que envie um pacote após o intervalo quando nada mais sai.

Dois erros explicam a maior parte da confusão aqui. Copiar a sua própria chave privada para um bloco peer faz com que as duas pontas partilhem uma identidade, e o handshake falha de uma forma que fica mal registada. Endpoint deixar de fora num cliente costuma ser intencional, porque o servidor aprende o endereço a partir do handshake de entrada; deixá-lo de fora num servidor que tem de iniciar não é. Lembre-se também de que o keepalive mantém um mapeamento NAT aberto, e não melhora o débito nem reduz a latência, por isso trinta segundos de pacotes extra não compram nada quando o tráfego já flui.

AllowedIPs é encaminhamento, não uma lista de permissões

AllowedIPs é o encaminhamento por chave criptográfica do WireGuard. À saída, decide qual peer recebe um pacote com base no destino. À entrada, decide se um pacote que chega desse peer é aceite com base na origem. O mesmo campo faz as duas tarefas, por isso não é uma lista de controlo de acesso nem uma lista de sites permitidos.

Um AllowedIPs estreito no servidor para um cliente significa que o servidor só aceitará pacotes que declarem essas origens e só enviará esses destinos a esse cliente. Alargue um lado sem alargar o outro e obtém um túnel que sobe e não deixa passar nada.

O que o wg-quick acrescenta em torno do protocolo

wg-quick lê o mesmo ficheiro e executa os passos de rede que o protocolo deixa ao sistema operativo. Atribui o endereço da interface, acrescenta rotas derivadas de AllowedIPs, escreve as definições do resolvedor e executa os comandos de gancho por ordem.

Essa camada explica a assimetria clássica. Um ficheiro com 0.0.0.0/0 e uma linha DNS dá ao cliente uma rota predefinida e um resolvedor, e não faz absolutamente nada às regras de reencaminhamento ou NAT do servidor. Essas pertencem à configuração do próprio servidor, e nenhum ficheiro de cliente as pode fornecer.

Mantenha um único dono do ficheiro. Editá-lo à mão enquanto SaveConfig está ativo significa que a sua edição desaparece da próxima vez que a interface descer, e a interface não lhe dirá que isso aconteceu.

Verifique o estado aplicado, não o ficheiro

O ficheiro é uma intenção. O estado aplicado é o que o núcleo guarda, e divergem sempre que um auxiliar, um drop-in ou um gancho editou algo depois da ativação.

Leia o estado vivo e o endereçamento em conjunto e depois compare ambos com o que escreveu:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Se a lista de peers estiver vazia, a interface foi criada sem que a sua configuração fosse aplicada. Se existirem endereços e rotas mas os contadores ficarem a zero, o ficheiro foi carregado e o handshake está a falhar, o que é um problema de chave ou de extremidade e não de ordem das secções. Compare as duas vistas antes de editar, porque a diferença entre elas costuma ser a falha real.