WireGuard 5G na filial: deixe a filial discar para o hub

Apontar uma filial para um hub é a metade fácil deste projeto quando a filial fica atrás de um endereço móvel variável e o hub tem um nome estável. O hub então aprende a filial do tráfego autenticado, em vez de um registo que precisa de manter atualizado. O contrato é simples: a filial inicia sempre.

Configure-o deliberadamente e depois verifique a parte que as pessoas assumem funcionar. Ambos os passos levam minutos, e é no segundo que estes projetos costumam falhar.

Que lado detém o ponto final estável

A configuração da filial indica o ponto final e a chave pública do hub. A configuração do hub indica a chave pública da filial e os seus prefixos internos permitidos, e pode não ter qualquer ponto final, porque a identidade vem da chave e não do endereço de origem do último pacote. Essa assimetria é todo o mecanismo, e elimina uma classe inteira de problemas de descoberta do lado do hub.

Quando a filial envia um pacote autenticado, o hub registra a origem de onde veio e usa esse mapeamento nas respostas. Renumerar a ligação móvel passa então a não custar nada além do próximo aperto de mão, e cada componente de que já não precisa é um que não pode falhar durante uma mudança. Vale a pena testar essa propriedade numa alteração planeada e não durante um incidente. Faça-o enquanto alguém pode observar as duas pontas ao mesmo tempo.

Dê à filial uma configuração que sobreviva à renumeração

Mantenha o ponto final e o keepalive na filial, e mantenha a entrada de par do hub livre de um endereço codificado fixo. O keepalive mantém o mapeamento traduzido aberto o tempo suficiente para o hub enviar tráfego não solicitado depois de um período inativo.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Vinte e cinco segundos é o exemplo citado com frequência para manter um mapeamento NAT vivo, não um requisito para cada par. Defina-o conforme o tempo limite de mapeamento que observa na realidade, e lembre-se de que gera tráfego numa ligação com limite de dados enquanto a interface estiver ativa.

No hub, os prefixos permitidos do par da filial têm de cobrir tudo o que a filial enviar. Um prefixo em falta comporta-se como uma falha de encaminhamento na ponta remota e não produz qualquer aviso em nenhum dos lados, por isso vale a pena revê-lo antes do primeiro pacote real. Compare os prefixos permitidos do hub com os endereços de interface da filial antes da primeira ligação.

Verifique o mapeamento e a comutação

Confirme que o aperto de mão se completa, que o hub lista o ponto final atual da filial e que os endereços internos da filial são alcançáveis através do túnel. Essa é a linha de base, e deve ser registada antes de alguém tocar na ligação móvel. Duas linhas de saída bastam. Guarde-as no ticket com a marca temporal.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Depois teste a falha para a qual o projeto existe. Retire o WAN principal e confirme que a rota subjacente da filial para o hub passa agora pela interface móvel. Um túnel não consegue reparar um caminho físico quebrado, por isso uma rota externa que ainda aponta para um uplink morto produz um tempo limite de aperto de mão que parece exatamente um problema do hub.

Se o caminho externo estiver explicitamente ligado ou encaminhado por política, a comutação tem de o incluir. Essa lacuna entre um projeto que se lê corretamente e um que sobrevive a uma falha é normalmente a única coisa que falta.

O que este projeto não resolve

Nada aqui admite uma ligação de entrada para a filial. Se algo na sede tiver de discar para o local móvel, a direção do túnel está errada para esse requisito, e o DNS dinâmico apenas atualiza um nome. A tradução do operador, a política de entrada e a atualização do ponto final pelo cliente continuam todas no caminho, e um registo alterado não consegue abrir NAT de nível de operadora.

Mantenha o prefixo da filial distinto de qualquer outro local, e limite o que a sua gateway irá reencaminhar. O ponto final estável do hub simplifica a descoberta e não faz nada pelo projeto de encaminhamento, pelo planeamento de endereços ou pela questão de que rotas de aplicação sobrevivem a uma comutação.

Escreva quatro coisas no runbook: quem inicia, que prefixos são permitidos, quanto dura o keepalive e o que acontece quando a ligação principal cai. Essas linhas são o que um operador futuro realmente precisa às três da manhã.