Nebula static_host_map: la dirección que un faro no puede dar

Cada faro puede contar a un host sobre cualquier otro par, excepto dónde vive el propio faro. Algo tiene que saberse antes de que exista el overlay, y Nebula pone ese algo en un mapa pequeño. El mapa empareja una identidad de overlay con una dirección que funciona en la red ordinaria. Todo lo que se aprende después depende de que ese emparejamiento sea correcto.

Dos direcciones con dos trabajos

Cada host de Nebula posee una dirección de overlay que permanece fija mientras el dispositivo se mueve entre redes. Esa dirección es la identidad que usan los certificados, las reglas de cortafuegos y las relaciones entre pares, y por sí sola no enruta a ninguna parte. El extremo alcanzable es otra cosa: un nombre de host o una dirección en la red subyacente más un puerto UDP, y cambia cada vez que la máquina cambia de ubicación. El mapa estático es la unión entre las dos.

En el mapa solo entran los hosts que deben marcarse en frío, lo que normalmente significa los faros y quizá un relay. Mantener esa lista corta es un objetivo de diseño, porque cada entrada manual se convierte en un hecho que alguien tiene que mantener. Confundir los dos tipos de dirección es el error de configuración habitual: una dirección pública puesta en la lista de faros no hace que empiece el descubrimiento.

La identidad va donde se espera identidad. La alcanzabilidad va en el mapa.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomía de una entrada del mapa

La clave es la dirección de overlay escrita como una cadena entre comillas, y el valor es una lista de extremos, así que una identidad puede tener varias puertas de entrada. Cada extremo lleva un host y un puerto, y el puerto debe coincidir con lo que la otra parte escucha realmente. El valor predeterminado de Nebula es UDP 4242, que es un punto de partida y no una promesa sobre tu despliegue.

Varios extremos son útiles cuando un faro tiene más de un camino de entrada, como una dirección pública y una dirección privada para hosts del mismo segmento. El cliente los prueba en orden, así que pon el más fiable primero. Para IPv6, pon la dirección entre corchetes antes de añadir el puerto; equivocarse aquí produce un error de análisis que señala la línea incorrecta.

Un puerto equivocado produce silencio en lugar de un error, porque UDP no tiene handshake que rechazar. Por eso vale la pena comprobar el formato de la entrada contra la referencia de static_host_map de Nebula y no contra la memoria. La referencia también cubre las listas de extremos y el comportamiento de actualización de DNS.

El arranque tiene que funcionar antes del overlay

Un nombre DNS del mapa debe resolverse mediante el resolutor que el host tiene antes de que exista cualquier túnel, es decir, el resolutor ordinario del sistema. Pruébalo desde la misma máquina, al arrancar, con el overlay detenido. Un nombre que solo se resuelve mediante el DNS propio del overlay no puede arrancar el overlay. La misma prueba se aplica a la ruta: una regla de cortafuegos que permite el overlay pero no el primer intercambio UDP bloquea el paquete inicial.

Comprueba el puerto con una herramienta UDP en lugar de suponer que está abierto. Confirma que cualquier reenvío de puerto en el camino apunta al host interno correcto y que existe un camino de vuelta. Si el nombre de host se resuelve a varias direcciones, prueba cada una, porque el cliente puede elegir una dirección que nunca comprobaste.

Las entradas estáticas se marcan directamente y nunca consultan a un faro. Por eso un fallo aquí parece un tiempo de espera normal sin ningún par implicado.

Qué pasa después del primer handshake

Cuando un host llega a un faro, aprende sobre los pares y sus direcciones alcanzables sin más entradas manuales. Los hosts que se han movido desde la última conexión se vuelven descubribles por ese canal. Esa es la recompensa de mantener pequeño el mapa manual.

Los hosts también pueden anunciar direcciones alcanzables adicionales propias, y así un par detrás de una dirección pública conocida ayuda a los demás a encontrarlo. Esos anuncios se aprenden, no se escriben en el mapa estático.

El comportamiento de actualización importa para los extremos escritos como nombres DNS, porque una dirección resuelta puede cambiar mientras el proceso sigue en marcha. Los ajustes de Nebula controlan cómo se hacen esas consultas, incluido qué resolutor se usa, así que léelos en lugar de suponer el valor predeterminado del sistema. En un host cuyo resolutor cambia cuando sube un túnel, el ajuste equivocado puede convertir un arranque funcional en un nombre que deja de resolverse a mitad de sesión. Fijar la consulta a un resolutor estable suele ser la diferencia entre un overlay fiable y uno intermitente.

Cuando el descubrimiento funciona y un par no

Si los faros son alcanzables y la mayoría de los pares se conectan, el arranque no es el problema. El par restante o no encuentra un camino usable entre sí o falla por encima de la alcanzabilidad. Añadir otra grafía de la dirección del faro no puede reparar ninguno de los dos casos.

Comprueba el par antes de editar el mapa en el que ya se apoya todo lo demás. Un cambio de mapa perturba a todos los hosts, así que es lo último que se toca, no lo primero.

Empieza con certificados de la misma autoridad, porque un handshake rechazado puede parecer de lejos un par inalcanzable. Luego comprueba si el par puede establecer un camino directo y si hay un relay configurado para redes que rechazan el tráfico directo. Un relay añade un salto y una dependencia, pero es una respuesta soportada, y arreglar el camino del par es una tarea distinta de arreglar el descubrimiento.