Nebula static_host_map: o endereço que um farol não pode dar

Cada farol pode contar a um host sobre qualquer outro par, exceto onde o próprio farol fica. Algo tem de ser conhecido antes de o overlay existir, e a Nebula põe esse algo num mapa pequeno. O mapa emparelha uma identidade de overlay com um endereço que funciona na rede comum. Tudo o que se aprende depois depende de esse emparelhamento estar correto.

Dois endereços com duas funções

Cada host Nebula possui um endereço de overlay que permanece fixo enquanto o dispositivo se move entre redes. Esse endereço é a identidade usada por certificados, regras de firewall e relações entre pares, e por si só não encaminha para lado nenhum. O extremo alcançável é outra coisa: um nome de host ou endereço na rede subjacente mais uma porta UDP, e muda sempre que a máquina troca de localização. O mapa estático é a junção entre os dois.

Só entram no mapa os hosts que têm de ser marcados a frio, o que normalmente significa os faróis e talvez um relay. Manter essa lista curta é um objetivo de projeto, porque cada entrada manual se torna um facto que alguém tem de manter. Confundir os dois tipos de endereço é o erro de configuração habitual: um endereço público colocado na lista de faróis não faz o descobrimento começar.

A identidade vai onde se espera identidade. A alcançabilidade vai no mapa.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomia de uma entrada do mapa

A chave é o endereço de overlay escrito como uma cadeia entre aspas, e o valor é uma lista de extremos, pelo que uma identidade pode ter várias portas de entrada. Cada extremo leva um host e uma porta, e a porta tem de corresponder ao que o outro lado escuta de facto. O valor predefinido da Nebula é UDP 4242, que é um ponto de partida e não uma promessa sobre a tua implementação.

Vários extremos são úteis quando um farol tem mais do que um caminho de entrada, como um endereço público e um endereço privado para hosts do mesmo segmento. O cliente experimenta-os por ordem, por isso põe o mais fiável primeiro. Para IPv6, põe o endereço entre parênteses retos antes de acrescentar a porta; enganar-se aqui produz um erro de análise que aponta para a linha errada.

Uma porta errada produz silêncio em vez de um erro, porque o UDP não tem handshake para recusar. Por isso vale a pena verificar o formato da entrada contra a referência static_host_map da Nebula e não contra a memória. A referência também cobre as listas de extremos e o comportamento de atualização do DNS.

O arranque tem de funcionar antes do overlay

Um nome DNS do mapa tem de ser resolvido pelo resolvedor que o host tem antes de existir qualquer túnel, ou seja, o resolvedor comum do sistema. Testa-o da mesma máquina, no arranque, com o overlay parado. Um nome que só se resolve pelo DNS próprio do overlay não pode arrancar o overlay. O mesmo teste aplica-se à rota: uma regra de firewall que permite o overlay mas não a primeira troca UDP bloqueia o pacote inicial.

Verifica a porta com uma ferramenta UDP em vez de assumir que está aberta. Confirma que qualquer redirecionamento de porta no caminho aponta para o host interno certo e que existe um caminho de volta. Se o nome de host se resolver em vários endereços, testa cada um, porque o cliente pode escolher um endereço que nunca verificaste.

As entradas estáticas são marcadas diretamente e nunca consultam um farol. Por isso uma falha aqui parece um tempo de espera comum sem qualquer par envolvido.

O que acontece depois do primeiro handshake

Quando um host chega a um farol, aprende sobre os pares e os seus endereços alcançáveis sem mais entradas manuais. Os hosts que se moveram desde a última ligação tornam-se descobríveis por esse canal. É essa a recompensa de manter pequeno o mapa manual.

Os hosts também podem anunciar endereços alcançáveis adicionais próprios, e é assim que um par atrás de um endereço público conhecido ajuda os outros a encontrá-lo. Esses anúncios são aprendidos, não são escritos no mapa estático.

O comportamento de atualização importa para os extremos escritos como nomes DNS, porque um endereço resolvido pode mudar enquanto o processo continua a correr. As definições da Nebula controlam como essas consultas acontecem, incluindo que resolvedor é usado, por isso lê-as em vez de assumir a predefinição do sistema. Num host cujo resolvedor muda quando sobe um túnel, a definição errada pode transformar um arranque funcional num nome que deixa de resolver a meio da sessão. Fixar a consulta a um resolvedor estável é muitas vezes a diferença entre um overlay fiável e um intermitente.

Quando o descobrimento funciona e um par não

Se os faróis são alcançáveis e a maioria dos pares se liga, o arranque não é o problema. O par restante ou não encontra um caminho utilizável entre si ou falha acima da alcançabilidade. Acrescentar outra grafia do endereço do farol não repara nenhum dos dois casos.

Verifica o par antes de editar o mapa em que tudo o resto já se apoia. Uma alteração do mapa perturba todos os hosts, por isso é a última coisa a tocar, não a primeira.

Começa com certificados da mesma autoridade, porque um handshake rejeitado pode parecer de longe um par inalcançável. Depois verifica se o par consegue estabelecer um caminho direto e se há um relay configurado para redes que recusam tráfego direto. Um relay acrescenta um salto e uma dependência, mas é uma resposta suportada, e corrigir o caminho do par é uma tarefa diferente de corrigir o descobrimento.