Relé de Nebula configurat però sense ús: tres ajustos per revisar

Has afegit un equip de relé, has posat la seva adreça de Nebula en una configuració, i els dos parells continuen sense comunicar-se. Passa perquè un camí de relé necessita que tres declaracions separades coincideixin, i només una d’elles viu a la màquina que probablement has editat. Ja hi he anat dos cops: una on l’equip de reenviament no havia rebut mai el rol de relé, i una on els ajustos estaven escrits al costat equivocat de la connexió. La seqüència de sota comprova el rol, l’anunci i el permís en aquest ordre, i cada pas té una ordre que et diu si has de continuar.

Dibuixa els tres rols abans d’editar una configuració

Nebula dona una feina a cada equip, i aquestes feines no s’hereten. Un lighthouse respon les preguntes de on és aquest parell perquè els equips es puguin trobar. Un relé reenvia trànsit entre dos parells que no tenen cap camí directe operatiu. Un equip normal no fa ni una cosa ni l’altra. Els tres ajustos que importen viuen en tres màquines diferents, i per això una configuració de client que sembla completa pot deixar els dos parells esperant.

# 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 sol símptoma separa les dues classes de fallada. Si els dos parells es llisten mútuament i el registre mostra intents de handshake que no s’acaben mai, el descobriment funciona i el camí de dades està bloquejat per NAT o per un tallafoc. Si un parell no arriba a saber mai l’adreça de l’altre, el problema és al lighthouse o al seu mapa estàtic d’equips, i els ajustos de relé no ho poden arreglar.

Confirma quina configuració ha carregat realment cada equip abans de tocar res més. Una unit que llegeix un camí diferent del fitxer que has editat és una causa comuna i incòmoda que «el canvi no fes res»:

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

La línia de versió importa en un parc mixt. El tractament de relés, el comportament del punching i les claus de configuració acceptades no són idèntics entre versions, així que no donis per fet que una compilació antiga entén una secció per a la qual no es va escriure. Alinea els equips a la mateixa sèrie menor, executa després nebula -test -config /etc/nebula/config.yml a cada equip i compara la sortida abans de depurar un transport que el codi no implementa.

Activa el rol de reenviament a l’equip de relé

El rol de relé és un sol indicador a l’equip de reenviament, i és independent de ser un lighthouse. Un equip amb el descobriment activat i el reenviament per relé desactivat només continua sent un servei de descobriment. Al relé:

relay:
  am_relay: true

Aquest indicador declara una intenció; no crea abastabilitat. Un relé ha de ser abastable des dels dos parells, cosa que en la pràctica vol dir una adreça pública, UDP d’entrada al port de Nebula obert al tallafoc de l’equip i a qualsevol grup de seguretat del núvol, i cap NAT doble al davant. Comprova el socket en escolta i després mira si arriben els paquets del parell:

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

Dos límits estalvien temps més endavant. No s’arriba a un relé a través d’un altre relé, així que una cadena de noms de relé en una configuració no substitueix donar a l’equip de reenviament un camí utilitzable. I un relé reenvia paquets; no concedeix permisos, les regles d’entrada de la destinació continuen decidint si es permet el flux retransmès. El rol i els seus requisits són a la documentació de configuració del relé.

Anuncia el relé des de la destinació, no des del client

Aquesta és la inversió que consumeix més hores. La llista de relés pertany a l’equip que vols assolir, perquè diu als altres parells quins relés es poden fer servir per arribar a aquell equip. Posar-la al client que inicia la connexió no aporta res a la direcció que el client necessita:

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

Els parells informen d’aquesta llista juntament amb les seves adreces quan es presenten al lighthouse, així que l’anunci es propaga pel descobriment i no per un intercanvi directe. Si la destinació no arriba a cap lighthouse, la seva llista de relés no es difon mai i un relé ben configurat queda inactiu. Aquesta fallada sembla exactament un relé espatllat i no ho és.

Dona a la destinació un camí d’arrencada a la mateixa passada. El mapa estàtic d’equips lliga una adreça de Nebula a un extrem públic perquè el primer handshake tingui on anar, i necessita una entrada per al relé si la destinació ha d’acceptar trànsit retransmès d’equips que no pot assolir directament:

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

Deixa que el parell que es connecta faci servir el relé

El costat que inicia necessita el seu propi permís. relay.use_relays és actiu per defecte, així que el cas que val la pena buscar és un false explícit, sovint copiat d’una plantilla escrita abans que existís la funció de relé o deixat per un intent anterior de forçar camins directes:

relay:
  use_relays: true

El permís d’aquest costat no és l’única porta. Les regles d’entrada de la destinació s’apliquen igualment al paquet retransmès, i la font amb què es comparen és la identitat dins del túnel i no l’adreça del relé mateix. Quan el handshake retransmès acaba i l’aplicació continua fallant, llegeix el registre de la destinació per veure quina font ha enregistrat abans de reescriure una regla.

Els ajustos de travessa de NAT interactuen amb tot això. punchy.punch ajuda dos parells a obrir un camí directe, i quan ho aconsegueix no hi ha trànsit de relé per observar; això és un èxit, no un relé absent. Una parella que funciona de manera intermitent sol voler dir que el punching encerta només de vegades, així que prova aquesta parella diverses vegades en lloc de treure’n una conclusió d’un sol intent.

Verifica amb la parella que ha fallat, i després recarrega

Prova els dos equips que han fallat de debò, amb l’aplicació que necessiten. Un ping correcte des de la teva estació de treball al servei del relé mateix no demostra res sobre el reenviament entre dos altres parells, i és el fals positiu més comú de tot aquest procediment.

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

Recarrega en lloc de reiniciar, i confirma que el procés en marxa ha recollit el fitxer que has editat. Un reinici tomba tots els túnels i fa que la prova següent sigui més difícil de llegir, mentre que un SIGHUP conserva el procés i li fa rellegir la configuració:

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

systemctl reload només funciona quan la unit local defineix ExecReload, i la unit que es distribueix amb el projecte no ho fa, així que systemctl kill -s HUP és el pas que funciona en una instal·lació estàndard. Després de la recàrrega, llegeix el journal pel camí de configuració que ha obert el procés, per saber que s’ha llegit el fitxer nou i no el que suposaves carregat.

Els ajustos de relé i el punching de NAT actuen tots dos sobre el camí; cap dels dos actua sobre la identitat. Si la parella continua fallant l’handshake un cop confirmats am_relay, relays i use_relays a la configuració en execució, comprova que els dos equips presenten certificats emesos per als noms amb què estan configurats i que la CA és la mateixa als dos costats. Mantén fixes la configuració de certificats i del tallafoc mentre canvies un ajust de transport cada vegada, perquè una edició de certificat i una edició de relé a la mateixa prova no et diuen quina de les dues ha mogut l’handshake. Un desajust de nom o de CA falla al mateix lloc que un relé que no s’ha trobat mai, i per això aquesta contracomprovació pertany a la mateixa passada.

Després confirma que cada declaració és al fitxer a què pertany:

• am_relay: true a l’equip de reenviament, i aquest equip abastable per UDP des dels dos costats.
• relays: amb l’adreça de Nebula d’aquest equip a la destinació.
• use_relays: true al parell que inicia la connexió.
• Regles d’entrada a la destinació que encara permeten la font real després del canvi de camí.