Nebula-relé konfigurert men ubrukt: tre innstillinger å kontrollere

Du la til en relévert, satte Nebula-adressen dens i en konfigurasjon, og de to peerne snakker fortsatt ikke sammen. Det skjer fordi en relévei trenger tre separate erklæringer som må stemme overens, og bare én av dem ligger på maskinen du sannsynligvis redigerte. Jeg har jaktet på dette to ganger: én gang der videresendingsverten aldri hadde fått relérollen, og én gang der innstillingene var skrevet på feil side av forbindelsen. Rekkefølgen nedenfor kontrollerer rollen, annonseringen og tillatelsen i den rekkefølgen, og hvert steg har en kommando som forteller deg om du skal fortsette.

Kartlegg de tre rollene før du redigerer en konfigurasjon

Nebula gir hver vert en jobb, og jobbene arves ikke. En lighthouse svarer på spørsmål som hvor er denne peeren, slik at verter kan finne hverandre. Et relé videresender trafikk mellom to peere som ikke har en fungerende direkte vei. En vanlig vert gjør ingen av delene. De tre innstillingene som betyr noe, ligger på tre forskjellige maskiner, og derfor kan en klientkonfigurasjon som ser komplett ut la begge peerne 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

Ett enkelt symptom skiller de to feilklassene. Hvis begge peerne lister hverandre og loggen viser håndtrykkforsøk som aldri fullføres, virker oppdagelsen, og dataveien blokkeres av NAT eller av en brannmur. Hvis en peer aldri får vite adressen til den andre, ligger problemet i lighthouse eller i det statiske vertskartet, og reléinnstillinger kan ikke reparere det.

Bekreft hvilken konfigurasjon hver vert faktisk har lastet før du endrer noe annet. En unit som leser en annen sti enn filen du redigerte, er en vanlig og pinlig årsak til at «endringen ikke gjorde noe»:

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

Versjonslinjen betyr noe i en blandet flåte. Reléhåndtering, punch-oppførsel og aksepterte konfigurasjonsnøkler er ikke identiske på tvers av utgivelser, så ikke anta at en eldre build forstår en seksjon den ikke er skrevet for. Sett vertene på samme minor-serie, kjør deretter nebula -test -config /etc/nebula/config.yml på hver vert og sammenlign utdata før du feilsøker en transport koden ikke implementerer.

Slå på videresendingsrollen på reléverten

Relérollen er et enkelt flagg på videresendingsverten, og den er atskilt fra å være en lighthouse. En vert med oppdagelse påslått og relévideresending avslått er fortsatt bare en oppdagelsestjeneste. På reléet:

relay:
  am_relay: true

Flagget erklærer en hensikt; det skaper ikke nåbarhet. Et relé må være nåbart fra begge peerne, noe som i praksis betyr en offentlig adresse, innkommende UDP på Nebula-porten åpen i vertens brannmur og i enhver sikkerhetsgruppe i skyen, og ingen dobbel NAT foran. Kontroller den lyttende socketen og se deretter om pakkene fra peeren kommer inn:

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

To grenser sparer tid senere. Et relé kan ikke nås gjennom et annet relé, så en kjede av relénavn i en konfigurasjon erstatter ikke en brukbar vei til videresendingsverten. Og et relé videresender pakker; det gir ikke tillatelse, de innkommende reglene til målet avgjør fortsatt om den videresendte strømmen er tillatt. Rollen og kravene til den er beskrevet i dokumentasjonen for relékonfigurasjon.

Annonser reléet fra målet, ikke fra klienten

Det er reverseringen som spiser flest timer. Relélisten hører til verten du prøver å nå, fordi den forteller andre peere hvilke reléer som kan brukes for å nå den verten. Å sette den på klienten som starter forbindelsen, gjør ingenting for retningen klienten trenger:

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

Peere rapporterer listen sammen med adressene sine når de melder seg hos lighthouse, så annonseringen sprer seg gjennom oppdagelsen og ikke gjennom en direkte utveksling. Hvis målet ikke når noen lighthouse, spres relélisten aldri, og et riktig konfigurert relé blir stående ledig. Den feilen ser nøyaktig ut som et ødelagt relé og er ikke det.

Gi målet en oppstartsvei i samme runde. Det statiske vertskartet binder en Nebula-adresse til et offentlig endepunkt slik at det første håndtrykket har et sted å gå, og det trenger en oppføring for reléet hvis målet skal godta videresendt trafikk fra verter det ikke kan nå direkte:

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

La peeren som kobler til bruke reléet

Den initierende siden trenger sin egen tillatelse. relay.use_relays er på som standard, så tilfellet som er verdt å lete etter, er en eksplisitt false, ofte kopiert fra en mal skrevet før reléfunksjonen fantes eller etterlatt av et tidligere forsøk på å tvinge fram direkte veier:

relay:
  use_relays: true

Tillatelse på denne siden er ikke den eneste porten. De innkommende reglene til målet gjelder fortsatt for den videresendte pakken, og kilden de matches mot er identiteten inne i tunnelen og ikke adressen til reléet selv. Når det videresendte håndtrykket fullføres og applikasjonen fortsatt feiler, les loggen til målet for kilden den registrerte før du skriver om en regel.

NAT-traverseringsinnstillinger samspiller med alt dette. punchy.punch hjelper to peere å åpne en direkte vei, og når det lykkes finnes det ingen relétrafikk å observere; det er suksess, ikke et manglende relé. Et par som virker av og til betyr vanligvis at punching lykkes noen ganger, så test det paret flere ganger i stedet for å trekke en konklusjon av ett forsøk.

Verifiser med paret som feilet, og last deretter inn på nytt

Test de to vertene som faktisk feilet, med applikasjonen de trenger. En vellykket ping fra arbeidsstasjonen din til reléets egen tjeneste beviser ingenting om videresending mellom to andre peere, og det er den vanligste falske positive i hele denne prosedyren.

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

Last inn på nytt i stedet for å starte på nytt, og bekreft at den kjørende prosessen har tatt opp filen du redigerte. En omstart river hver tunnel og gjør neste test vanskeligere å lese, mens en SIGHUP beholder prosessen og får den til å lese konfigurasjonen på nytt:

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

systemctl reload virker bare når den lokale uniten definerer ExecReload, og uniten som følger med prosjektet gjør det ikke, så systemctl kill -s HUP er steget som lykkes på en standardinstallasjon. Les journalen etter omlastingen for konfigurasjonsstien prosessen åpnet, slik at du vet at den nye filen ble lest og ikke den du antok var lastet.

Reléinnstillinger og NAT-punching virker begge på veien; ingen av dem virker på identiteten. Hvis paret fortsatt feiler håndtrykket når am_relay, relays og use_relays er bekreftet i den kjørende konfigurasjonen, kontroller at begge vertene viser sertifikater utstedt for navnene de er konfigurert med og at CA-en er den samme på begge sider. Hold sertifikat- og brannmurkonfigurasjonen fast mens du endrer én transportinnstilling om gangen, for en sertifikatendring og en reléendring i samme test forteller deg ingenting om hvilken av dem som flyttet håndtrykket. Et navne- eller CA-avvik feiler på samme sted som et relé som aldri ble funnet, og derfor hører denne motkontrollen til i samme runde.

Bekreft deretter at hver erklæring står i filen den hører til:

• am_relay: true på videresendingsverten, og den verten nåbar via UDP fra begge sider.
• relays: med Nebula-adressen til den verten på målet.
• use_relays: true på peeren som starter forbindelsen.
• Innkommende regler på målet som fortsatt tillater den ekte kilden etter at veien er endret.