Nebula-relay konfigureret men ubrugt: tre indstillinger at kontrollere

Du har tilføjet en relayhost, sat dens Nebula-adresse i en konfiguration, og de to peers taler stadig ikke sammen. Det sker, fordi en relayvej kræver tre separate erklæringer, der stemmer overens, og kun én af dem ligger på den maskine, du sandsynligvis har redigeret. Jeg har jagtet det her to gange: én gang hvor videresendelsesværten aldrig havde fået relayrollen, og én gang hvor indstillingerne var skrevet på den forkerte side af forbindelsen. Rækkefølgen nedenfor kontrollerer rollen, annonceringen og tilladelsen i den orden, og hvert trin har en kommando, der fortæller dig, om du skal fortsætte.

Kortlæg de tre roller, før du redigerer en konfiguration

Nebula giver hver host en opgave, og opgaverne nedarves ikke. En lighthouse besvarer spørgsmål som hvor er denne peer, så hosts kan finde hinanden. En relay videresender trafik mellem to peers, der ikke har en fungerende direkte vej. En almindelig host gør ingen af delene. De tre indstillinger, der betyder noget, ligger på tre forskellige maskiner, og derfor kan en klientkonfiguration, der ser komplet ud, lade begge peers vente.

# 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

Et enkelt symptom skiller de to fejlklasser. Hvis begge peers lister hinanden, og loggen viser handshakeforsøg, der aldrig fuldføres, virker opdagelsen, og datastien blokeres af NAT eller af en firewall. Hvis en peer slet ikke får kendskab til den andens adresse, ligger problemet i lighthouse eller i dens statiske hostmap, og relayindstillinger kan ikke reparere det.

Bekræft, hvilken konfiguration hver host faktisk har indlæst, før du ændrer noget andet. En unit, der læser en anden sti end den fil, du redigerede, er en almindelig og pinlig årsag til, at »ændringen ikke gjorde noget«:

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

Versionslinjen betyder noget i en blandet flåde. Relayhåndtering, punchadfærd og accepterede konfigurationsnøgler er ikke identiske på tværs af udgivelser, så antag ikke, at en ældre build forstår et afsnit, den ikke er skrevet til. Sæt hostene på samme minor-serie, kør derefter nebula -test -config /etc/nebula/config.yml på hver host og sammenlign outputtet, før du fejlsøger en transport, som koden ikke implementerer.

Slå videresendelsesrollen til på relayhosten

Relayrollen er et enkelt flag på videresendelsesværten, og den er adskilt fra at være en lighthouse. En host med opdagelse slået til og relayvideresendelse slået fra er stadig kun en opdagelsestjeneste. På relayen:

relay:
  am_relay: true

Flaget erklærer en hensigt; det skaber ikke rækkevidde. En relay skal kunne nås fra begge peers, hvilket i praksis betyder en offentlig adresse, indgående UDP på Nebula-porten åben i hostens firewall og i enhver cloud-sikkerhedsgruppe, og ingen dobbelt NAT foran. Kontrollér den lyttende socket, og se derefter, om peerens pakker ankommer:

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

To grænser sparer tid senere. En relay kan ikke nås gennem en anden relay, så en kæde af relaynavne i en konfiguration erstatter ikke en brugbar vej til videresendelsesværten. Og en relay videresender pakker; den giver ikke tilladelse, destinationens egne indgående regler afgør stadig, om den videresendte strøm er tilladt. Rollen og dens krav er beskrevet i dokumentationen om relaykonfiguration.

Annoncér relayen fra destinationen, ikke fra klienten

Det er den ombytning, der koster flest timer. Relaylisten hører til den host, du prøver at nå, fordi den fortæller andre peers, hvilke relays der må bruges til at nå den host. At sætte den på klienten, der starter forbindelsen, gør intet for den retning, klienten har brug for:

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

Peers rapporterer listen sammen med deres adresser, når de melder sig hos lighthouse, så annonceringen spredes gennem opdagelsen og ikke gennem en direkte udveksling. Hvis destinationen ikke kan nå en lighthouse, spredes dens relayliste aldrig, og en korrekt konfigureret relay forbliver ledig. Den fejl ligner præcis en defekt relay og er det ikke.

Giv destinationen en bootstrap-vej i samme omgang. Den statiske hostmap binder en Nebula-adresse til et offentligt endepunkt, så det første handshake har et sted at gå hen, og den skal have en post for relayen, hvis destinationen skal acceptere videresendt trafik fra hosts, den ikke kan nå direkte:

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

Lad den forbindende peer bruge relayen

Den initierende side har brug for sin egen tilladelse. relay.use_relays er slået til som standard, så det tilfælde, der er værd at lede efter, er en eksplicit false, ofte kopieret fra en skabelon skrevet før relayfunktionen fandtes eller efterladt af et tidligere forsøg på at tvinge direkte veje:

relay:
  use_relays: true

Tilladelse på denne side er ikke den eneste port. Destinationens indgående regler gælder stadig for den videresendte pakke, og den kilde, de matches mod, er identiteten inde i tunnelen og ikke relayens egen adresse. Når det videresendte handshake fuldføres, og applikationen stadig fejler, så læs destinationens log for den kilde, den registrerede, før du omskriver en regel.

NAT-traversalindstillinger spiller sammen med alt dette. punchy.punch hjælper to peers med at åbne en direkte vej, og når det lykkes, er der ingen relaytrafik at se; det er succes, ikke en manglende relay. Et par, der virker i perioder, betyder som regel, at punching lykkes nogle gange, så test det par flere gange i stedet for at drage en konklusion af et enkelt forsøg.

Verificér med det par, der fejlede, og genindlæs derefter

Test de to hosts, der faktisk fejlede, med den applikation, de har brug for. En vellykket ping fra din arbejdsstation til relayens egen tjeneste beviser intet om videresendelse mellem to andre peers, og det er den mest almindelige falske positiv i hele denne procedure.

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

Genindlæs i stedet for at genstarte, og bekræft, at den kørende proces har taget den fil, du redigerede. En genstart river hver tunnel ned og gør den næste test sværere at læse, mens en SIGHUP beholder processen og får den til at læse konfigurationen igen:

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

systemctl reload virker kun, når den lokale unit definerer ExecReload, og den unit, der følger med projektet, gør det ikke, så systemctl kill -s HUP er det trin, der lykkes på en standardinstallation. Læs journalen efter genindlæsningen for den konfigurationssti, processen åbnede, så du ved, at den nye fil blev læst og ikke den, du antog var indlæst.

Relayindstillinger og NAT-punching virker begge på vejen; ingen af dem virker på identiteten. Hvis parret stadig fejler sit handshake, når am_relay, relays og use_relays er bekræftet i den kørende konfiguration, så kontrollér, at begge hosts fremviser certifikater udstedt til de navne, de er konfigureret med, og at CA'en er den samme på begge sider. Hold certifikat- og firewallkonfigurationen fast, mens du ændrer én transportindstilling ad gangen, for en certifikatændring og en relayændring i samme test fortæller dig intet om, hvilken af dem der flyttede handshaket. En navne- eller CA-uoverensstemmelse fejler samme sted som en relay, der aldrig blev fundet, og derfor hører denne modkontrol i samme omgang.

Bekræft derefter, at hver erklæring står i den fil, den hører til:

• am_relay: true på videresendelsesværten, og den host kan nås via UDP fra begge sider.
• relays: med den hosts Nebula-adresse på destinationen.
• use_relays: true på den peer, der starter forbindelsen.
• Indgående regler på destinationen, der stadig tillader den rigtige kilde efter vejændringen.