Nebula advertise_addrs o static_host_map: elige según el propietario
El mapa estático lo mantiene cada peer que lo marca; la dirección anunciada la publica el host. Elige según quién conoce el extremo.
Los ajustes static_host_map y advertise_addrs colocan ambos una dirección delante de un peer, y responden preguntas distintas. Uno es un archivo local que enumera una dirección overlay y el extremo underlay al que marcar. El otro es un host que dice a sus faros qué extremos adicionales pueden alcanzarlo. La propiedad es la diferencia real: el mapa lo mantiene todo el que lo necesita, y el anuncio el propio host.
Decide según quién posee la información
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Cada peer cambiante en el archivo estático de cada peer es una tarea de mantenimiento que crece con el cuadrado de la flota. Esa es la razón práctica para recurrir al otro ajuste siempre que el propio host conozca la respuesta.
La pregunta de la propiedad también predice qué pasa cuando cambia una dirección. Con un mapa estático, alguien tiene que recordar cada peer que tiene la entrada antigua. Con un anuncio, el host publica el nuevo extremo y sus faros lo transmiten, así que el cambio se queda local en la máquina que se movió.
Bootstrap sigue necesitando entradas estáticas
Un cliente debe alcanzar al menos un faro antes de poder preguntar a nadie por otros peers. Ese primer salto no puede venir del descubrimiento, así que viene de una entrada estática en la configuración del cliente. Consigue que esa única entrada sea correcta y el resto del overlay se puede aprender.
Una entrada del mapa empareja una dirección Nebula con uno o más extremos IP o DNS alcanzables y puertos. Mantener allí los faros es normal; mantener allí cada peer es el patrón que envejece mal, porque cada peer nuevo significa editar archivos en máquinas que quizá no controles. Mantén la lista lo bastante corta para que una persona aún pueda verificarla leyéndola.
Anuncia cuando el host conoce el extremo
Un host detrás de reenvío de puertos es alcanzable en una dirección pública que no está asignada a ninguna de sus propias interfaces. No puede descubrir esa dirección mirándose a sí mismo. advertise_addrs le permite publicar el extremo a través de sus faros para que otros peers aprendan una ruta que funciona de verdad. El ajuste existe precisamente porque el host es la única parte que sabe que el mapeo se hizo.
Usa la dirección y el puerto que otros peers pueden alcanzar de verdad. El mismo razonamiento se aplica a un host con varias rutas de red, donde una ruta es preferible para los peers de una red concreta. El anuncio es una afirmación sobre el underlay, no una petición de nada. Cuando cambie el mapeo, actualiza el anuncio en el host y deja que el descubrimiento lo lleve, en lugar de editar archivos estáticos en toda la flota.
Anunciar no es ser alcanzable
Publicar un extremo no crea la regla de reenvío del router, no abre un firewall aguas arriba ni hace que un nombre DNS se resuelva. Son piezas de trabajo separadas, y un anuncio correcto con un reenvío de puerto ausente produce exactamente el fallo que intentabas arreglar. Anunciar es una afirmación sobre la alcanzabilidad, no un mecanismo que la establezca.
Comprueba la ruta desde fuera antes de culpar al descubrimiento. Un peer que aprende el extremo pero no puede completar un handshake tiene un problema de enrutamiento o filtrado en el underlay, y repetir la misma dirección en ambos ajustes no cambiará eso.
Mantén la dirección overlay separada del extremo
El certificado del nodo identifica su dirección Nebula. Las direcciones anunciadas pertenecen a la red subyacente y se pueden cambiar sin tocar el certificado. Emitir un certificado nuevo con una IP overlay distinta es una operación distinta, con sus propias consecuencias para cada relación de confianza que fijó la antigua. Mantén los dos cambios separados en el runbook, o un traslado de extremo se registrará como una reemisión.
Cuando el triaje se atasca, separa las dos capas explícitamente: ¿el descubrimiento devuelve el extremo esperado y un handshake llega a él? Si el descubrimiento es correcto y los paquetes fallan, el problema está por debajo del overlay. Si el descubrimiento es incorrecto, el problema está en el mapa o en el anuncio, y la corrección pertenece allí.