Relé de Nebula configurado pero sen uso: tres axustes que revisar

Engadiches un equipo de relé, puxeches o seu enderezo de Nebula nunha configuración e os dous pares seguen sen falar. Isto ocorre porque unha ruta de relé necesita tres declaracións separadas que coincidan, e só unha delas está na máquina que probablemente editaches. Xa me atopei con isto dúas veces: nunha, o equipo de reenvío nunca recibira o rol de relé, e noutra os axustes estaban escritos no lado equivocado da conexión. A secuencia de abaixo comproba o rol, o anuncio e o permiso nesa orde, e cada paso ten un comando que che di se debes continuar.

Distingue os tres roles antes de tocar unha configuración

Nebula dálle un traballo a cada equipo, e eses traballos non se herdan. Un lighthouse responde ás preguntas de onde está tal par para que os equipos poidan atoparse. Un relé reenvía tráfico entre dous pares que non teñen unha ruta directa operativa. Un equipo normal non fai ningunha das dúas cousas. Os tres axustes que importan viven en tres máquinas distintas, e por iso unha configuración de cliente que parece completa pode deixar os dous pares agardando.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Un só síntoma separa as dúas clases de fallo. Se os dous pares se listan entre si e o rexistro mostra intentos de handshake que nunca rematan, o descubrimento funciona e a ruta de datos está bloqueada por NAT ou por unha devasa. Se un par nunca chega a coñecer o enderezo do outro, o problema está no lighthouse ou no seu mapa estático de equipos, e os axustes de relé non poden arranxalo.

Confirma que configuración cargou realmente cada equipo antes de cambiar calquera outra cousa. Unha unit que le unha ruta distinta do ficheiro que editaches é unha causa común e vergoñenta de que «o cambio non fixera nada»:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

A liña de versión importa nun parque mixto. O tratamento de relés, o comportamento do punching e as chaves de configuración aceptadas non son idénticos entre versións, así que non deas por feito que unha compilación antiga entende unha sección para a que non se escribiu. Aliña os equipos na mesma serie menor, executa despois nebula -test -config /etc/nebula/config.yml en cada equipo e compara a saída antes de depurar un transporte que o código non implementa.

Activa o rol de reenvío no equipo de relé

O rol de relé é un só indicador no equipo de reenvío, e é independente de ser un lighthouse. Un equipo co descubrimento activado e o reenvío por relé desactivado segue sendo só un servizo de descubrimento. No relé:

relay:
  am_relay: true

Ese indicador declara unha intención; non crea alcanzabilidade. Un relé ten que ser alcanzable desde os dous pares, o que na práctica significa un enderezo público, UDP de entrada no porto de Nebula aberto na devasa do equipo e en calquera grupo de seguridade da nube, e ningún NAT dobre diante. Comproba o socket en escoita e despois observa se chegan os paquetes do par:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Dous límites aforran tempo despois. Non se chega a un relé a través doutro relé, así que unha cadea de nomes de relé nunha configuración non substitúe dar ao equipo de reenvío unha ruta utilizábel. E un relé reenvía paquetes; non concede permisos, as regras de entrada do destino seguen decidindo se se permite o fluxo reenviado. O rol e os seus requisitos están na documentación de configuración do relé.

Anuncia o relé desde o destino, non desde o cliente

Esta é a inversión que consome máis horas. A lista de relés pertence ao equipo ao que tentas chegar, porque lles indica aos outros pares que relés poden usarse para alcanzar ese equipo. Pórlla no cliente que inicia a conexión non achega nada á dirección que o cliente necesita:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Os pares informan desa lista xunto cos seus enderezos cando se presentan no lighthouse, así que o anuncio se propaga mediante o descubrimento e non mediante un intercambio directo. Se o destino non alcanza ningún lighthouse, a súa lista de relés nunca se difunde e un relé ben configurado permanece inactivo. Ese fallo parécese exactamente a un relé roto e non o é.

Dálle ao destino unha ruta de arranque na mesma pasada. O mapa estático de equipos liga un enderezo de Nebula a un extremo público para que o primeiro handshake teña onde ir, e necesita unha entrada para o relé se o destino debe aceptar tráfico reenviado de equipos aos que non pode chegar directamente:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Deixa que o par que se conecta use o relé

O lado que inicia necesita o seu propio permiso. relay.use_relays está activo por defecto, así que o caso que paga a pena buscar é un false explícito, moitas veces copiado dun modelo escrito antes de que existise a función de relé ou deixado por un intento anterior de forzar rutas directas:

relay:
  use_relays: true

O permiso deste lado non é a única porta. As regras de entrada do destino séguense aplicando ao paquete reenviado, e a fonte coa que se comparan é a identidade dentro do túnel e non o enderezo do propio relé. Cando o handshake reenviado remata e a aplicación segue fallando, le o rexistro do destino para ver que fonte rexistrou antes de reescribir unha regra.

Os axustes de travesía de NAT interactúan con todo isto. punchy.punch axuda a dous pares a abrir unha ruta directa, e cando o consegue non hai tráfico de relé que observar; iso é un éxito, non un relé ausente. Un par que funciona de forma intermitente adoita significar que o punching acerta só ás veces, así que proba ese par varias veces en vez de sacar unha conclusión dun só intento.

Verifica co par que fallou e despois recarga

Proba os dous equipos que fallaron de verdade, coa aplicación que necesitan. Un ping correcto desde a túa estación de traballo ao servizo do propio relé non demostra nada sobre o reenvío entre outros dous pares, e é o falso positivo máis común de todo este procedemento.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Recarga en lugar de reiniciar, e confirma que o proceso en marcha recolleu o ficheiro que editaches. Un reinicio derruba todos os túneles e fai que a proba seguinte sexa máis difícil de ler, mentres que un SIGHUP conserva o proceso e fai que relea a configuración:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload só funciona cando a unit local define ExecReload, e a unit que se distribúe co proxecto non o fai, así que systemctl kill -s HUP é o paso que funciona nunha instalación estándar. Despois da recarga, le o journal para a ruta de configuración que abriu o proceso, para saber que se leu o ficheiro novo e non o que supuñas cargado.

Os axustes de relé e o punching de NAT actúan ambos sobre a ruta; ningún actúa sobre a identidade. Se o par segue fallando o handshake unha vez confirmados am_relay, relays e use_relays na configuración en execución, comproba que os dous equipos presentan certificados emitidos para os nomes cos que están configurados e que a CA é a mesma nos dous lados. Mantén fixa a configuración de certificados e da devasa mentres cambias un axuste de transporte cada vez, porque unha edición de certificado e unha edición de relé na mesma proba non che din cal das dúas moveu o handshake. Un desaxuste de nome ou de CA falla no mesmo sitio que un relé que nunca se atopou, e por iso esta contracomprobación pertence á mesma pasada.

Despois confirma que cada declaración está no ficheiro ao que pertence:

• am_relay: true no equipo de reenvío, e ese equipo alcanzable por UDP desde os dous lados.
• relays: co enderezo de Nebula dese equipo no destino.
• use_relays: true no par que inicia a conexión.
• Regras de entrada no destino que seguen permitindo a fonte real despois do cambio de ruta.