Nebula-relä konfigurerat men oanvänt: tre inställningar att kontrollera

Du har lagt till en relävärd, satt dess Nebula-adress i en konfiguration, och de två peerna pratar fortfarande inte med varandra. Det beror på att en reläväg kräver tre separata utsagor som stämmer överens, och bara en av dem finns på maskinen du förmodligen redigerade. Jag har jagat det här två gånger: en gång hade vidarebefordringsvärden aldrig fått relärollen, och en gång var inställningarna skrivna på fel sida av anslutningen. Sekvensen nedan kontrollerar rollen, annonseringen och behörigheten i den ordningen, och varje steg har ett kommando som säger om du ska fortsätta.

Kartlägg de tre rollerna innan du redigerar en konfiguration

Nebula ger varje värd en uppgift, och uppgifterna ärvs inte. En lighthouse svarar på frågor som var finns den här peern så att värdar kan hitta varandra. Ett relä vidarebefordrar trafik mellan två peerar som inte har någon fungerande direktväg. En vanlig värd gör inget av det. De tre inställningarna som spelar roll ligger på tre olika maskiner, och därför kan en klientkonfiguration som ser komplett ut låta båda peerna vänta.

# 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

Ett enda symptom skiljer de två felklasserna. Om båda peerna listar varandra och loggen visar handskakningsförsök som aldrig slutförs fungerar upptäckten, och datavägen blockeras av NAT eller av en brandvägg. Om en peer aldrig får veta den andras adress ligger problemet i lighthouse eller i dess statiska värdkarta, och reläinställningar kan inte reparera det.

Bekräfta vilken konfiguration varje värd faktiskt har laddat innan du ändrar något annat. En unit som läser en annan sökväg än filen du redigerade är en vanlig och pinsam orsak till att »ändringen inte gjorde något«:

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

Versionsraden spelar roll i en blandad flotta. Relähantering, punchbeteende och accepterade konfigurationsnycklar är inte identiska mellan utgåvor, så utgå inte från att en äldre build förstår ett avsnitt som den inte skrevs för. Lägg värdarna på samma minor-serie, kör sedan nebula -test -config /etc/nebula/config.yml på varje värd och jämför utdata innan du felsöker en transport som koden inte implementerar.

Aktivera vidarebefordringsrollen på relävärden

Relärollen är en enda flagga på vidarebefordringsvärden, och den är skild från att vara en lighthouse. En värd med upptäckt påslagen och relävidarebefordran avstängd är fortfarande bara en upptäcktstjänst. På reläet:

relay:
  am_relay: true

Flaggan deklarerar en avsikt; den skapar ingen nåbarhet. Ett relä måste vara nåbart från båda peerna, vilket i praktiken betyder en publik adress, inkommande UDP på Nebula-porten öppen i värdens brandvägg och i varje molnsäkerhetsgrupp, och ingen dubbel NAT framför. Kontrollera den lyssnande socketen och se sedan om peerns paket anländer:

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

Två gränser sparar tid senare. Ett relä går inte att nå genom ett annat relä, så en kedja av relänamn i en konfiguration ersätter inte en användbar väg till vidarebefordringsvärden. Och ett relä vidarebefordrar paket; det ger ingen behörighet, målets egna inkommande regler avgör fortfarande om det vidarebefordrade flödet tillåts. Rollen och dess krav beskrivs i dokumentationen om reläkonfiguration.

Annonsera reläet från målet, inte från klienten

Det är omkastningen som kostar flest timmar. Relälistan hör till värden du försöker nå, eftersom den talar om för andra peerar vilka reläer som får användas för att nå den värden. Att sätta den på klienten som startar anslutningen gör ingenting för den riktning klienten behöver:

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

Peerar rapporterar listan tillsammans med sina adresser när de anmäler sig hos lighthouse, så annonseringen sprids genom upptäckten och inte genom ett direkt utbyte. Om målet inte når någon lighthouse sprids dess relälista aldrig, och ett korrekt konfigurerat relä förblir overksamt. Det felet ser exakt ut som ett trasigt relä och är inte det.

Ge målet en bootstrap-väg i samma omgång. Den statiska värdkartan knyter en Nebula-adress till en publik ändpunkt så att den första handskakningen har någonstans att ta vägen, och den behöver en post för reläet om målet ska acceptera vidarebefordrad trafik från värdar det inte kan nå direkt:

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

Låt peern som ansluter använda reläet

Den initierande sidan behöver sin egen behörighet. relay.use_relays är på som standard, så fallet som är värt att leta efter är en explicit false, ofta kopierad från en mall skriven innan reläfunktionen fanns eller kvarlämnad av ett tidigare försök att tvinga fram direkta vägar:

relay:
  use_relays: true

Behörighet på den här sidan är inte den enda porten. Målets inkommande regler gäller fortfarande för det vidarebefordrade paketet, och den källa de matchar är identiteten inne i tunneln och inte reläets egen adress. När den vidarebefordrade handskakningen slutförs och applikationen fortfarande misslyckas, läs målets logg efter den källa den registrerade innan du skriver om en regel.

NAT-traverseringsinställningar samverkar med allt detta. punchy.punch hjälper två peerar att öppna en direktväg, och när det lyckas finns ingen relätrafik att observera; det är framgång, inte ett saknat relä. Ett par som fungerar intermittent brukar betyda att punchningen lyckas ibland, så testa det paret flera gånger i stället för att dra en slutsats av ett enda försök.

Verifiera med paret som misslyckades och ladda sedan om

Testa de två värdar som faktiskt misslyckades, med applikationen de behöver. En lyckad ping från din arbetsstation till reläets egen tjänst bevisar ingenting om vidarebefordran mellan två andra peerar, och det är den vanligaste falska positiva i hela den här proceduren.

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

Ladda om i stället för att starta om, och bekräfta att den körande processen har tagit upp filen du redigerade. En omstart river varje tunnel och gör nästa test svårare att läsa, medan en SIGHUP behåller processen och får den att läsa konfigurationen igen:

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

systemctl reload fungerar bara när den lokala uniten definierar ExecReload, och uniten som följer med projektet gör det inte, så systemctl kill -s HUP är steget som lyckas på en standardinstallation. Läs journalen efter omladdningen för den konfigurationssökväg processen öppnade, så att du vet att den nya filen lästes och inte den du antog var laddad.

Reläinställningar och NAT-punchning verkar båda på vägen; ingen av dem verkar på identiteten. Om paret fortfarande misslyckas med sin handskakning när am_relay, relays och use_relays är bekräftade i den körande konfigurationen, kontrollera att båda värdarna visar certifikat utfärdade för de namn de är konfigurerade med och att CA:n är densamma på båda sidor. Håll certifikat- och brandväggskonfigurationen fast medan du ändrar en transportinställning i taget, för en certifikatändring och en reläändring i samma test säger ingenting om vilken av dem som flyttade handskakningen. En namn- eller CA-avvikelse misslyckas på samma ställe som ett relä som aldrig hittades, och därför hör den här motkontrollen till samma omgång.

Bekräfta sedan att varje utsaga står i filen den hör till:

• am_relay: true på vidarebefordringsvärden, och den värden nåbar via UDP från båda sidor.
• relays: med den värdens Nebula-adress på målet.
• use_relays: true på peern som startar anslutningen.
• Inkommande regler på målet som fortfarande tillåter den riktiga källan efter vägändringen.