Relé do Nebula configurado mas sem uso: três ajustes para conferir

Você adicionou um host de relay, colocou o endereço Nebula dele numa configuração e os dois peers continuam sem se falar. Isso acontece porque um caminho de relay precisa que três declarações separadas concordem, e apenas uma delas fica na máquina que você provavelmente editou. Já persegui isso duas vezes: numa, o host de encaminhamento nunca tinha recebido a função de relay; na outra, os ajustes estavam escritos do lado errado da conexão. A sequência abaixo confere a função, o anúncio e a permissão nessa ordem, e cada passo traz um comando que diz se você deve continuar.

Mapeie as três funções antes de editar uma configuração

O Nebula dá uma tarefa a cada host, e essas tarefas não são herdadas. Um lighthouse responde a perguntas do tipo onde está este peer para que os hosts se encontrem. Um relay encaminha tráfego entre dois peers que não têm um caminho direto funcional. Um host comum não faz nenhuma das duas coisas. Os três ajustes que importam ficam em três máquinas diferentes, e é por isso que uma configuração de cliente que parece completa pode deixar os dois peers esperando.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Um único sintoma separa as duas classes de falha. Se os dois peers se listam um ao outro e o log mostra tentativas de handshake que nunca terminam, a descoberta está funcionando e o caminho de dados está bloqueado por NAT ou por um firewall. Se um peer nunca descobre o endereço do outro, o problema está no lighthouse ou no mapa estático de hosts dele, e ajustes de relay não conseguem corrigir isso.

Confirme qual configuração cada host realmente carregou antes de editar qualquer outra coisa. Uma unit que lê um caminho diferente do arquivo que você editou é uma causa comum e embaraçosa de «a mudança não fez nada»:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

A linha de versão importa num parque misto. O tratamento de relay, o comportamento de punching e as chaves de configuração aceitas não são idênticos entre versões, então não presuma que um build antigo entende uma seção para a qual não foi escrito. Alinhe os hosts na mesma série menor, execute depois nebula -test -config /etc/nebula/config.yml em cada host e compare a saída antes de depurar um transporte que o código não implementa.

Ative a função de encaminhamento no host de relay

A função de relay é um único flag no host de encaminhamento, e é separada de ser um lighthouse. Um host com descoberta ativada e encaminhamento por relay desativado continua sendo apenas um serviço de descoberta. No relay:

relay:
  am_relay: true

Esse flag declara uma intenção; ele não cria alcance. Um relay precisa ser alcançável a partir dos dois peers, o que na prática significa um endereço público, UDP de entrada na porta do Nebula aberto no firewall do host e em qualquer grupo de segurança da nuvem, e nenhum NAT duplo na frente. Confira o socket em escuta e depois observe se os pacotes do peer chegam:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Dois limites economizam tempo mais tarde. Não se chega a um relay através de outro relay, então uma cadeia de nomes de relay numa configuração não substitui dar ao host de encaminhamento um caminho utilizável. E um relay encaminha pacotes; ele não concede permissão, as regras de entrada do destino continuam decidindo se o fluxo retransmitido é permitido. A função e os requisitos dela estão na documentação de configuração de relay.

Anuncie o relay a partir do destino, não do cliente

É essa inversão que consome mais horas. A lista de relays pertence ao host que você quer alcançar, porque informa aos outros peers quais relays podem ser usados para chegar a esse host. Colocá-la no cliente que inicia a conexão não faz nada pela direção de que o cliente precisa:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Os peers informam essa lista junto com os endereços quando se apresentam ao lighthouse, então o anúncio se propaga pela descoberta e não por uma troca direta. Se o destino não alcança nenhum lighthouse, a lista de relays dele nunca se espalha e um relay configurado corretamente fica ocioso. Essa falha parece exatamente um relay quebrado e não é.

Dê ao destino um caminho de bootstrap na mesma passada. O mapa estático de hosts liga um endereço Nebula a um endpoint público para que o primeiro handshake tenha para onde ir, e ele precisa de uma entrada para o relay se o destino deve aceitar tráfego retransmitido de hosts que não alcança diretamente:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Deixe o peer que se conecta usar o relay

O lado que inicia precisa da própria permissão. relay.use_relays vem ativado por padrão, então o caso que vale caçar é um false explícito, muitas vezes copiado de um modelo escrito antes de a função de relay existir ou deixado por uma tentativa anterior de forçar caminhos diretos:

relay:
  use_relays: true

A permissão deste lado não é o único portão. As regras de entrada do destino continuam valendo para o pacote retransmitido, e a origem com que elas comparam é a identidade dentro do túnel, não o endereço do próprio relay. Quando o handshake retransmitido termina e a aplicação ainda falha, leia o log do destino para ver a origem que ele registrou antes de reescrever uma regra.

Os ajustes de travessia de NAT interagem com tudo isso. punchy.punch ajuda dois peers a abrir um caminho direto, e quando consegue não há tráfego de relay para observar; isso é sucesso, não um relay ausente. Um par que funciona de forma intermitente costuma significar que o punching acerta só às vezes, então teste esse par várias vezes em vez de tirar uma conclusão de uma tentativa.

Verifique com o par que falhou e depois recarregue

Teste os dois hosts que realmente falharam, com a aplicação de que precisam. Um ping bem-sucedido da sua estação de trabalho para o serviço do próprio relay não prova nada sobre o encaminhamento entre outros dois peers, e é o falso positivo mais comum de todo este procedimento.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Recarregue em vez de reiniciar, e confirme que o processo em execução pegou o arquivo que você editou. Um reinício derruba todos os túneis e torna o teste seguinte mais difícil de ler, enquanto um SIGHUP mantém o processo e o faz reler a configuração:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload só funciona quando a unit local define ExecReload, e a unit que vem com o projeto não define, então systemctl kill -s HUP é o passo que funciona numa instalação padrão. Depois da recarga, leia o journal para o caminho de configuração que o processo abriu, para saber que o arquivo novo foi lido e não o que você supunha carregado.

Ajustes de relay e punching de NAT agem os dois sobre o caminho; nenhum age sobre a identidade. Se o par ainda falha o handshake depois de am_relay, relays e use_relays confirmados na configuração em execução, verifique se os dois hosts apresentam certificados emitidos para os nomes com que estão configurados e se a CA é a mesma dos dois lados. Mantenha a configuração de certificados e do firewall fixa enquanto muda um ajuste de transporte por vez, porque uma edição de certificado e uma edição de relay no mesmo teste não dizem qual das duas moveu o handshake. Um descompasso de nome ou de CA falha no mesmo lugar que um relay que nunca foi encontrado, e é por isso que essa contraprova pertence à mesma passada.

Depois confirme que cada declaração está no arquivo a que pertence:

• am_relay: true no host de encaminhamento, e esse host alcançável por UDP dos dois lados.
• relays: nomeando o endereço Nebula desse host no destino.
• use_relays: true no peer que inicia a conexão.
• Regras de entrada no destino que ainda permitem a origem real depois da mudança de caminho.