Nebula advertise_addrs ou static_host_map: escolha pelo proprietário

As configurações static_host_map e advertise_addrs ambas colocam um endereço à frente de um peer, e respondem a perguntas diferentes. Uma é um ficheiro local que lista um endereço overlay e o endpoint underlay a discar. A outra é um host que diz aos seus faróis que endpoints adicionais conseguem alcançá-lo. A propriedade é a diferença real: o mapa é mantido por todos os que precisam dele, e o anúncio pelo próprio host.

Decida por quem é dono da informação

Cada peer que muda no ficheiro estático de cada peer é trabalho de manutenção que cresce com o quadrado da frota. É a razão prática para recorrer à outra configuração sempre que o próprio host sabe a resposta.

A questão da propriedade também prevê o que acontece quando um endereço muda. Com um mapa estático, alguém tem de se lembrar de cada peer que guarda a entrada antiga. Com um anúncio, o host publica o novo endpoint e os seus faróis transmitem-no, por isso a mudança fica local na máquina que se moveu.

O bootstrap ainda precisa de entradas estáticas

Um cliente tem de alcançar pelo menos um farol antes de poder perguntar a alguém sobre outros peers. Esse primeiro salto não pode vir da descoberta, por isso vem de uma entrada estática na configuração do cliente. Corrija essa única entrada e o resto do overlay pode ser aprendido.

Uma entrada do mapa emparelha um endereço Nebula com um ou mais endpoints IP ou DNS alcançáveis e portas. Manter ali os faróis é normal; manter ali cada peer é o padrão que envelhece mal, porque cada peer novo significa editar ficheiros em máquinas que pode não controlar. Mantenha a lista curta o suficiente para que uma pessoa ainda a possa verificar lendo-a.

Anuncie quando o host conhece o endpoint

Um host atrás de reencaminhamento de portas é alcançável num endereço público que não está atribuído a nenhuma das suas próprias interfaces. Não pode descobrir esse endereço olhando para si mesmo. advertise_addrs permite-lhe publicar o endpoint através dos seus faróis para que outros peers aprendam um caminho que funciona mesmo. A configuração existe precisamente porque o host é a única parte que sabe que o mapeamento foi feito.

Use o endereço e a porta que outros peers conseguem realmente alcançar. O mesmo raciocínio aplica-se a um host com vários caminhos de rede, onde um caminho é preferível para peers numa rede concreta. O anúncio é uma afirmação sobre o underlay, não um pedido de nada. Quando o mapeamento muda, atualize o anúncio no host e deixe a descoberta levá-lo, em vez de editar ficheiros estáticos em toda a frota.

Anunciar não é alcançabilidade

Publicar um endpoint não cria a regra de reencaminhamento do router, não abre uma firewall a montante nem faz um nome DNS resolver. São peças de trabalho separadas, e um anúncio correto com um reencaminhamento de porta em falta produz exatamente a falha que tentava corrigir. Anunciar é uma afirmação sobre a alcançabilidade, não um mecanismo que a estabelece.

Verifique o caminho de fora antes de culpar a descoberta. Um peer que aprende o endpoint mas não consegue completar um handshake tem um problema de encaminhamento ou filtragem no underlay, e repetir o mesmo endereço em ambas as configurações não mudará isso.

Mantenha o endereço overlay separado do endpoint

O certificado do nó identifica o seu endereço Nebula. Os endereços anunciados pertencem à rede subjacente, e podem mudar sem tocar no certificado. Emitir um novo certificado com um IP overlay diferente é uma operação diferente, com as suas próprias consequências para cada relação de confiança que fixou a antiga. Mantenha as duas mudanças separadas no runbook, ou uma mudança de endpoint será registada como uma reemissão.

Quando o triage bloqueia, separe as duas camadas explicitamente: a descoberta devolve o endpoint esperado, e um handshake chega a ele? Se a descoberta está correta e os pacotes falham, o problema está abaixo do overlay. Se a descoberta está errada, o problema está no mapa ou no anúncio, e a correção pertence ali.