Nebula static_host_map: o enderezo que un faro non pode dar

Cada faro pode contar a un host sobre calquera outro par, agás onde vive o propio faro. Algo ten que saberse antes de que exista o overlay, e Nebula pon ese algo nun mapa pequeno. O mapa emparexa unha identidade de overlay cun enderezo que funciona na rede ordinaria. Todo o que se aprende despois depende de que ese emparexamento sexa correcto.

Dous enderezos con dous traballos

Cada host de Nebula posúe un enderezo de overlay que permanece fixo mentres o dispositivo se move entre redes. Ese enderezo é a identidade que usan os certificados, as regras de cortalumes e as relacións entre pares, e por si só non encamiña a ningures. O extremo alcanzable é outra cousa: un nome de host ou un enderezo na rede subxacente máis un porto UDP, e cambia cada vez que a máquina cambia de localización. O mapa estático é a unión entre os dous.

No mapa só entran os hosts que deben marcarse en frío, o que normalmente significa os faros e quizais un repetidor. Manter esa lista curta é un obxectivo de deseño, porque cada entrada manual convértese nun feito que alguén ten que manter. Confundir os dous tipos de enderezo é o erro de configuración habitual: un enderezo público posto na lista de faros non fai comezar o descubrimento.

A identidade vai onde se espera identidade. A alcanzabilidade vai no mapa.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomía dunha entrada do mapa

A clave é o enderezo de overlay escrito como unha cadea entre comiñas, e o valor é unha lista de extremos, así que unha identidade pode ter varias portas de entrada. Cada extremo leva un host e un porto, e o porto debe coincidir co que a outra parte escoita realmente. O valor predeterminado de Nebula é UDP 4242, que é un punto de partida e non unha promesa sobre o teu despregamento.

Varios extremos son útiles cando un faro ten máis dun camiño de entrada, como un enderezo público e un enderezo privado para hosts do mesmo segmento. O cliente probaos por orde, así que pon o máis fiable primeiro. Para IPv6, pon o enderezo entre corchetes antes de engadir o porto; equivocarse aquí produce un erro de análise que sinala a liña incorrecta.

Un porto equivocado produce silencio en lugar dun erro, porque UDP non ten handshake que rexeitar. Por iso paga a pena comprobar o formato da entrada contra a referencia de static_host_map de Nebula e non contra a memoria. A referencia tamén cobre as listas de extremos e o comportamento de actualización de DNS.

O arranque ten que funcionar antes do overlay

Un nome DNS do mapa debe resolverse mediante o resolutor que o host ten antes de que exista calquera túnel, é dicir, o resolutor ordinario do sistema. Probao desde a mesma máquina, ao arrincar, co overlay detido. Un nome que só se resolve mediante o DNS propio do overlay non pode arrincar o overlay. A mesma proba aplícase á ruta: unha regra de cortalumes que permite o overlay pero non o primeiro intercambio UDP bloquea o paquete inicial.

Comproba o porto cunha ferramenta UDP en lugar de supor que está aberto. Confirma que calquera redirección de porto no camiño apunta ao host interno correcto e que existe un camiño de volta. Se o nome de host se resolve a varios enderezos, proba cada un, porque o cliente pode escoller un enderezo que nunca comprobaches.

As entradas estáticas márcanse directamente e nunca consultan un faro. Por iso un fallo aquí parece un tempo de espera normal sen ningún par implicado.

Que pasa despois do primeiro handshake

Cando un host chega a un faro, aprende sobre os pares e os seus enderezos alcanzables sen máis entradas manuais. Os hosts que se moveron desde a última conexión vólvense descubribles por esa canle. Esa é a recompensa de manter pequeno o mapa manual.

Os hosts tamén poden anunciar enderezos alcanzables adicionais propios, e así un par detrás dun enderezo público coñecido axuda aos demais a atopalos. Eses anuncios apréndense, non se escriben no mapa estático.

O comportamento de actualización importa para os extremos escritos como nomes DNS, porque un enderezo resolto pode cambiar mentres o proceso segue en marcha. Os axustes de Nebula controlan como se fan esas consultas, incluído que resolutor se usa, así que leos en lugar de supor o valor predeterminado do sistema. Nun host cuxo resolutor cambia cando sobe un túnel, o axuste equivocado pode converter un arrinque funcional nun nome que deixa de resolverse a metade de sesión. Fixar a consulta a un resolutor estable adoita ser a diferenza entre un overlay fiable e un intermitente.

Cando o descubrimento funciona e un par non

Se os faros son alcanzables e a maioría dos pares se conectan, o arrinque non é o problema. O par restante ou non atopa un camiño usable entre si ou falla por riba da alcanzabilidade. Engadir outra grafía do enderezo do faro non pode reparar ningún dos dous casos.

Comproba o par antes de editar o mapa no que xa se apoia todo o demais. Un cambio de mapa perturba todos os hosts, así que é o último que se toca, non o primeiro.

Comeza con certificados da mesma autoridade, porque un handshake rexeitado pode parecer de lonxe un par inalcanzable. Logo comproba se o par pode establecer un camiño directo e se hai un repetidor configurado para redes que rexeitan o tráfico directo. Un repetidor engade un salto e unha dependencia, pero é unha resposta soportada, e arranxar o camiño do par é unha tarefa distinta de arranxar o descubrimento.