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

Du la til ein relévert, sette Nebula-adressa hans i ein konfigurasjon, og dei to peerane snakkar framleis ikkje saman. Det skjer fordi ein reléveg treng tre separate erklæringar som må stemme overeins, og berre éin av dei ligg på maskina du truleg redigerte. Eg har jakta på dette to gonger: éi gong der videresendingsverten aldri hadde fått relérolla, og éi gong der innstillingane var skrivne på feil side av sambandet. Rekkjefølgja nedanfor kontrollerer rolla, annonseringa og løyvet i den rekkjefølgja, og kvart steg har ein kommando som fortel deg om du skal halde fram.

Kartlegg dei tre rollene før du redigerer ein konfigurasjon

Nebula gir kvar vert ein jobb, og jobbane blir ikkje arva. Ein lighthouse svarar på spørsmål som kvar er denne peeren, slik at vertar kan finne kvarandre. Eit relé videresender trafikk mellom to peerar som ikkje har ein fungerande direkte veg. Ein vanleg vert gjer ingen av delane. Dei tre innstillingane som betyr noko, ligg på tre ulike maskiner, og difor kan ein klientkonfigurasjon som ser komplett ut la begge peerane 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

Eitt einskilt symptom skil dei to feilklassane. Viss begge peerane listar kvarandre og loggen viser handtrykkforsøk som aldri blir fullførte, verkar oppdaginga, og datavegen blir blokkert av NAT eller av ein brannmur. Viss ein peer aldri får vite adressa til den andre, ligg problemet i lighthouse eller i det statiske vertskartet, og reléinnstillingar kan ikkje reparere det.

Stadfest kva konfigurasjon kvar vert faktisk har lasta før du endrar noko anna. Ein unit som les ein annan sti enn fila du redigerte, er ein vanleg og pinleg årsak til at «endringa ikkje gjorde noko»:

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

Versjonslinja betyr noko i ein blanda flåte. Reléhandtering, punch-åtferd og aksepterte konfigurasjonsnøklar er ikkje identiske på tvers av utgjevingar, så ikkje gå ut frå at ein eldre build forstår ein seksjon han ikkje er skriven for. Set vertane på same minor-serie, køyr deretter nebula -test -config /etc/nebula/config.yml på kvar vert og samanlikn utdata før du feilsøkjer ein transport koden ikkje implementerer.

Slå på videresendingsrolla på reléverten

Relérolla er eit einskilt flagg på videresendingsverten, og ho er skild frå å vere ein lighthouse. Ein vert med oppdaging påslått og relévideresending avslått er framleis berre ein oppdagingsteneste. På reléet:

relay:
  am_relay: true

Flagget erklærer ei meining; det skapar ikkje nåbarheit. Eit relé må vere nåbart frå begge peerane, noko som i praksis betyr ei offentleg adresse, innkommande UDP på Nebula-porten open i brannmuren til verten og i kvar tryggingsgruppe i skya, og inga dobbel NAT framfor. Kontroller den lyttande socketen og sjå deretter om pakkane frå peeren kjem inn:

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

To grenser sparer tid seinare. Eit relé kan ikkje nåast gjennom eit anna relé, så ei kjede av relénamn i ein konfigurasjon erstattar ikkje ein brukbar veg til videresendingsverten. Og eit relé videresender pakkar; det gir ikkje løyve, dei innkommande reglane til målet avgjer framleis om den videresende straumen er tillaten. Rolla og krava til ho er skildra i dokumentasjonen for relékonfigurasjon.

Annonser reléet frå målet, ikkje frå klienten

Det er reverseringa som et flest timar. Relélista høyrer til verten du prøver å nå, fordi ho fortel andre peerar kva relé som kan brukast for å nå den verten. Å setje ho på klienten som startar sambandet, gjer ingenting for retninga klienten treng:

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

Peerar rapporterer lista saman med adressene sine når dei melder seg hos lighthouse, så annonseringa spreier seg gjennom oppdaginga og ikkje gjennom ein direkte utveksling. Viss målet ikkje når nokon lighthouse, blir relélista aldri spreidd, og eit rett konfigurert relé blir ståande ledig. Den feilen ser nøyaktig ut som eit øydelagt relé og er ikkje det.

Gi målet ein oppstartsveg i same runde. Det statiske vertskartet bind ei Nebula-adresse til eit offentleg endepunkt slik at det første handtrykket har ein stad å gå, og det treng ei oppføring for reléet viss målet skal godta videresendt trafikk frå vertar det ikkje kan nå direkte:

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

Lat peeren som koplar til bruke reléet

Den initierande sida treng sitt eige løyve. relay.use_relays er på som standard, så tilfellet som er verdt å leite etter, er ein eksplisitt false, ofte kopiert frå ein mal skriven før reléfunksjonen fanst eller etterlaten av eit tidlegare forsøk på å tvinge fram direkte vegar:

relay:
  use_relays: true

Løyve på denne sida er ikkje den einaste porten. Dei innkommande reglane til målet gjeld framleis for den videresende pakken, og kjelda dei blir matche mot er identiteten inne i tunnelen og ikkje adressa til reléet sjølv. Når det videresende handtrykket er fullført og applikasjonen framleis feilar, les loggen til målet for kjelda han registrerte før du skriv om ei regel.

NAT-traverseringsinnstillingar samspelar med alt dette. punchy.punch hjelper to peerar å opne ein direkte veg, og når det lykkast finst det ingen relétrafikk å observere; det er suksess, ikkje eit manglande relé. Eit par som verkar av og til betyr vanlegvis at punching lykkast nokre gonger, så test det paret fleire gonger i staden for å trekkje ei slutning av eitt forsøk.

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

Test dei to vertane som faktisk feila, med applikasjonen dei treng. Ein vellukka ping frå arbeidsstasjonen din til tenesta til reléet sjølv beviser ingenting om videresending mellom to andre peerar, og det er den vanlegaste falske positive i heile denne prosedyren.

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

Last inn på nytt i staden for å starte på nytt, og stadfest at den køyrande prosessen har teke opp fila du redigerte. Ein omstart riv kvar tunnel og gjer neste test vanskelegare å lese, medan ein SIGHUP behald prosessen og får han 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 verkar berre når den lokale uniten definerer ExecReload, og uniten som følgjer med prosjektet gjer det ikkje, så systemctl kill -s HUP er steget som lykkast på ein standardinstallasjon. Les journalen etter omlastinga for konfigurasjonsstien prosessen opna, slik at du veit at den nye fila vart lesen og ikkje den du antok var lasta.

Reléinnstillingar og NAT-punching verkar begge på vegen; ingen av dei verkar på identiteten. Viss paret framleis feilar handtrykket når am_relay, relays og use_relays er stadfesta i den køyrande konfigurasjonen, kontroller at begge vertane viser sertifikat utstedte for namna dei er konfigurerte med og at CA-en er den same på begge sider. Hald sertifikat- og brannmurkonfigurasjonen fast medan du endrar éi transportinnstilling om gongen, for ei sertifikatendring og ei reléendring i same test fortel deg ingenting om kva av dei som flytta handtrykket. Eit namne- eller CA-avvik feilar på same stad som eit relé som aldri vart funne, og difor høyrer denne motkontrollen til i same runde.

Stadfest deretter at kvar erklæring står i fila ho høyrer til:

• am_relay: true på videresendingsverten, og den verten nåbar via UDP frå begge sider.
• relays: med Nebula-adressa til den verten på målet.
• use_relays: true på peeren som startar sambandet.
• Innkommande reglar på målet som framleis tillèt den ekte kjelda etter at vegen er endra.