Nebula advertise_addrs ou static_host_map: escolle segundo o propietario

Os axustes static_host_map e advertise_addrs colocan ambos unha dirección diante dun peer, e responden preguntas distintas. Un é un ficheiro local que enumera unha dirección overlay e o extremo underlay ao que marcar. O outro é un host que lles di aos seus faros que extremos adicionais poden alcanzalo. A propiedade é a diferenza real: o mapa manténo todo o que o necesita, e o anuncio o propio host.

Decide segundo quen posúe a información

Cada peer cambiante no ficheiro estático de cada peer é unha tarefa de mantemento que crece co cadrado da frota. Esa é a razón práctica para acudir ao outro axuste sempre que o propio host coñeza a resposta.

A pregunta da propiedade tamén predí que pasa cando cambia unha dirección. Cun mapa estático, alguén ten que lembrar cada peer que ten a entrada antiga. Cun anuncio, o host publica o novo extremo e os seus faros transmíteno, así que o cambio queda local na máquina que se moveu.

Bootstrap segue necesitando entradas estáticas

Un cliente debe alcanzar polo menos un faro antes de poder preguntar a ninguén por outros peers. Ese primeiro salto non pode vir do descubrimento, así que vén de unha entrada estática na configuración do cliente. Fai correcta esa única entrada e o resto do overlay pódese aprender.

Unha entrada do mapa emparexa unha dirección Nebula cun ou máis extremos IP ou DNS alcanzables e portos. Manter alí os faros é normal; manter alí cada peer é o patrón que envellece mal, porque cada peer novo significa editar ficheiros en máquinas que quizais non controles. Mantén a lista o bastante curta para que unha persoa aínda poida verificala lendoa.

Anuncia cando o host coñece o extremo

Un host detrás de reenvío de portos é alcanzable nunha dirección pública que non está asignada a ningunha das súas propias interfaces. Non pode descubrir esa dirección mirándose a si mesmo. advertise_addrs permítelle publicar o extremo a través dos seus faros para que outros peers aprendan unha ruta que realmente funciona. O axuste existe precisamente porque o host é a única parte que sabe que se fixo o mapeo.

Usa a dirección e o porto que outros peers poden alcanzar de verdade. O mesmo razoamento se aplica a un host con varias rutas de rede, onde unha ruta é preferible para os peers dunha rede concreta. O anuncio é unha afirmación sobre o underlay, non unha petición de nada. Cando cambie o mapeo, actualiza o anuncio no host e deixa que o descubrimento o leve, en lugar de editar ficheiros estáticos por toda a frota.

Anunciar non é ser alcanzable

Publicar un extremo non crea a regra de reenvío do router, non abre un firewall augas arriba nin fai que un nome DNS se resolva. Son pezas de traballo separadas, e un anuncio correcto cun reenvío de porto ausente produce exactamente o fallo que intentabas arranxar. Anunciar é unha afirmación sobre a alcanzabilidade, non un mecanismo que a estableza.

Comproba a ruta desde fóra antes de culpar o descubrimento. Un peer que aprende o extremo pero non pode completar un handshake ten un problema de encamiñamento ou filtrado no underlay, e repetir a mesma dirección en ambos axustes non cambiará iso.

Mantén a dirección overlay separada do extremo

O certificado do nodo identifica a súa dirección Nebula. As direccións anunciadas pertencen á rede subxacente e pódense cambiar sen tocar o certificado. Emitir un certificado novo cunha IP overlay distinta é unha operación distinta, coas súas propias consecuencias para cada relación de confianza que fixou a antiga. Mantén os dous cambios separados no runbook, ou un traslado de extremo rexistrarase como unha reemisión.

Cando o triaxe se atasca, separa as dúas capas explicitamente: o descubrimento devolve o extremo esperado, e un handshake chega a el? Se o descubrimento é correcto e os paquetes fallan, o problema está por baixo do overlay. Se o descubrimento é incorrecto, o problema está no mapa ou no anuncio, e a corrección pertence alí.