Nebula-relay opgestel maar ongebruik: drie instellings om na te gaan

Jy het ’n relay-gasheer bygevoeg, sy Nebula-adres in ’n opstelling gesit, en die twee eweknieë praat steeds nie met mekaar nie. Dit gebeur omdat ’n relay-roete drie afsonderlike verklarings nodig het wat moet ooreenstem, en net een daarvan staan op die masjien wat jy waarskynlik geredigeer het. Ek het dit al twee keer agternagesit: een keer waar die deurstuur-gasheer nooit die relay-rol gekry het nie, en een keer waar die instellings aan die verkeerde kant van die verbinding geskryf is. Die volgorde hieronder gaan die rol, die aankondiging en die toestemming in daardie orde na, en elke stap het ’n opdrag wat jou sê of jy moet voortgaan.

Karteer die drie rolle voordat jy ’n opstelling wysig

Nebula gee elke gasheer ’n taak, en die take word nie geërf nie. ’n Lighthouse beantwoord vrae soos waar is hierdie eweknie sodat gashere mekaar kan vind. ’n Relay stuur verkeer deur tussen twee eweknieë wat geen werkende direkte roete het nie. ’n Gewone gasheer doen nie een van die twee nie. Die drie instellings wat saak maak, staan op drie verskillende masjiene, en daarom kan ’n kliënt-opstelling wat volledig lyk beide eweknieë laat wag.

# 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

Een simptoom skei die twee foutklasse. As beide eweknieë mekaar lys en die log toon handdruk-pogings wat nooit voltooi nie, werk die ontdekking en word die dataroete deur NAT of deur ’n firewall geblokkeer. As ’n eweknie die ander se adres glad nie leer ken nie, is die probleem by die lighthouse of by sy statiese gasheerkaart, en relay-instellings kan dit nie regmaak nie.

Bevestig watter opstelling elke gasheer werklik gelaai het voordat jy enigiets anders wysig. ’n Unit wat ’n ander pad lees as die lêer wat jy geredigeer het, is ’n algemene en verleë oorsaak van „die wysiging het niks gedoen”:

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

Die weergawelyn maak saak in ’n gemengde vloot. Relay-hantering, punch-gedrag en aanvaarde opstellingsleutels is nie oral oor uitgawes identies nie, moenie aanneem dat ’n ouer bou ’n afdeling verstaan waarvoor dit nie geskryf is nie. Sit die gashere op dieselfde minor-reeks, voer daarna nebula -test -config /etc/nebula/config.yml op elke gasheer uit en vergelyk die uitset voordat jy ’n vervoer ontfout wat die kode nie implementeer nie.

Aktiveer die deurstuur-rol op die relay-gasheer

Die relay-rol is een vlag op die deurstuur-gasheer, en dit staan apart van om ’n lighthouse te wees. ’n Gasheer met ontdekking aan en relay-deursturing af is steeds net ’n ontdekkingsdiens. Op die relay:

relay:
  am_relay: true

Daardie vlag verklaar ’n bedoeling; dit skep geen bereikbaarheid nie. ’n Relay moet van beide eweknieë af bereikbaar wees, wat in die praktyk ’n openbare adres beteken, inkomende UDP op die Nebula-poort oop in die gasheer se firewall en in enige wolk-sekuriteitsgroep, en geen dubbele NAT voor dit nie. Gaan die luisterende socket na en kyk dan of die eweknie se pakkette aankom:

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

Twee grense spaar later tyd. ’n Relay is nie deur ’n ander relay bereikbaar nie, so ’n ketting van relay-name in ’n opstelling vervang nie ’n bruikbare roete na die deurstuur-gasheer nie. En ’n relay stuur pakkette deur; dit verleen geen toestemming nie, die bestemming se eie inkomende reëls besluit steeds of die deurgestuurde stroom toegelaat word. Die rol en sy vereistes staan in die dokumentasie oor relay-opstelling.

Kondig die relay vanaf die bestemming aan, nie vanaf die kliënt nie

Dit is die omkering wat die meeste ure vreet. Die relay-lys hoort by die gasheer wat jy probeer bereik, want dit sê vir ander eweknieë watter relays gebruik mag word om daardie gasheer te bereik. Om dit op die kliënt te sit wat die verbinding begin, doen niks vir die rigting wat die kliënt nodig het nie:

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

Eweknieë rapporteer daardie lys saam met hul adresse wanneer hulle by die lighthouse aanmeld, so die aankondiging versprei deur die ontdekking en nie deur ’n direkte uitruiling nie. As die bestemming geen lighthouse bereik nie, versprei sy relay-lys nooit nie en ’n korrek opgestelde relay bly ledig. Daardie fout lyk presies soos ’n stukkende relay en is dit nie.

Gee die bestemming ’n bootstrap-roete in dieselfde ronde. Die statiese gasheerkaart bind ’n Nebula-adres aan ’n openbare eindpunt sodat die eerste handdruk êrens heen kan gaan, en dit het ’n inskrywing vir die relay nodig as die bestemming deurgestuurde verkeer van gashere moet aanvaar wat dit nie direk bereik nie:

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

Laat die verbindende eweknie die relay gebruik

Die inisiërende kant het sy eie toestemming nodig. relay.use_relays is by verstek aan, so die geval wat die moeite werd is om te soek is ’n eksplisiete false, dikwels gekopieer uit ’n sjabloon wat geskryf is voordat die relay-funksie bestaan het of agtergelaat deur ’n vroeëre poging om direkte roetes af te dwing:

relay:
  use_relays: true

Toestemming aan hierdie kant is nie die enigste hek nie. Die bestemming se inkomende reëls geld steeds vir die deurgestuurde pakket, en die bron waarmee hulle vergelyk word is die identiteit binne die tonnel en nie die relay se eie adres nie. Wanneer die deurgestuurde handdruk voltooi en die toepassing faal steeds, lees die bestemming se log vir die bron wat dit aangeteken het voordat jy ’n reël herskryf.

NAT-deurgang-instellings werk hiermee saam. punchy.punch help twee eweknieë om ’n direkte roete oop te maak, en as dit slaag is daar geen relay-verkeer om te sien nie; dit is sukses, nie ’n ontbrekende relay nie. ’n Paar wat met tussenposes werk, beteken gewoonlik dat die punch soms slaag, so toets daardie paar verskeie kere eerder as om uit een poging ’n gevolgtrekking te maak.

Verifieer met die paar wat gefaal het en herlaai dan

Toets die twee gashere wat werklik gefaal het, met die toepassing wat hulle nodig het. ’n Geslaagde ping van jou werkstasie na die relay se eie diens bewys niks oor deursturing tussen twee ander eweknieë nie, en dit is die algemeenste vals positief in hierdie hele prosedure.

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

Herlaai eerder as om weer te begin, en bevestig dat die lopende proses die lêer opgetel het wat jy geredigeer het. ’n Herbegin breek elke tonnel af en maak die volgende toets moeiliker leesbaar, terwyl ’n SIGHUP die proses hou en dit die opstelling weer laat inlees:

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

systemctl reload werk net as die plaaslike unit ExecReload definieer, en die unit wat met die projek saamkom doen dit nie, so systemctl kill -s HUP is die stap wat op ’n standaardinstallasie slaag. Lees ná die herlaai die joernaal vir die opstellingspad wat die proses oopgemaak het, sodat jy weet dat die nuwe lêer gelees is en nie die een wat jy aangeneem het gelaai was nie.

Relay-instellings en NAT-punching werk albei op die roete; nie een werk op die identiteit nie. As die paar steeds sy handdruk misluk nadat am_relay, relays en use_relays in die lopende opstelling bevestig is, gaan na of beide gashere sertifikate toon wat uitgereik is vir die name waarmee hulle opgestel is en of die CA aan beide kante dieselfde is. Hou die sertifikaat- en firewall-opstelling vas terwyl jy een vervoerinstelling op ’n slag verander, want ’n sertifikaatwysiging en ’n relay-wysiging in dieselfde toets sê vir jou niks oor watter een die handdruk verskuif het nie. ’n Naam- of CA-afwyking faal op dieselfde plek as ’n relay wat nooit gevind is nie, en daarom hoort hierdie teenkontrole in dieselfde ronde.

Bevestig dan dat elke verklaring in die lêer staan waar dit hoort:

• am_relay: true op die deurstuur-gasheer, en daardie gasheer van beide kante af per UDP bereikbaar.
• relays: met daardie gasheer se Nebula-adres op die bestemming.
• use_relays: true op die eweknie wat die verbinding begin.
• Inkomende reëls op die bestemming wat die werklike bron ná die roeteverandering steeds toelaat.