Do hast in relayhost tafoege, syn Nebula-adres yn in konfiguraasje set, en de twa peers prate noch altyd net mei elkoar. Dat komt trochdat in relaypaad trije aparte ferklearrings nedich hat dy’t oerienkomme moatte, en mar ien dêrfan stiet op de masine dy’t do wierskynlik bewurke hast. Ik haw dit twa kear neigien: ien kear wêrby’t de trochstjoerende host nea de relayrol krigen hie, en ien kear wêrby’t de ynstellings oan de ferkearde kant fan de ferbining skreaun wiene. De folchoarder hjirûnder kontrolearret de rol, de oankundiging en de tastimming yn dy folchoarder, en elke stap hat in opdracht dy’t dy fertelt oft do trochgean moat.

Bring de trije rollen yn kaart foardat do in konfiguraasje bewurkest

Nebula jout elke host in taak, en dy taken wurde net erfd. In lighthouse beantwurdet fragen as wêr is dizze peer, sadat hosts elkoar fine kinne. In relay stjoert ferkear troch tusken twa peers dy’t gjin wurkjend direkt paad hawwe. In gewoane host docht gjin fan beide. De trije ynstellings dy’t der ta dogge, steane op trije ferskillende masines, en dêrom kin in klantkonfiguraasje dy’t folslein liket beide peers wachtsje litte.

# 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

Ien symptoom skiedt de twa flaterklassen. As beide peers elkoar listje en it logboek hânskodzjenbesykjen toant dy’t nea foltôge wurde, wurket de ûntdekking en wurdt it datapaad blokkearre troch NAT of troch in firewall. As in peer it adres fan de oare hielendal net leart, sit it probleem by de lighthouse of by syn statyske hostkaart, en relayynstellings kinne dat net reparearje.

Kontrolearje hokker konfiguraasje elke host eins laden hat foardat do eat oars feroarest. In unit dy’t in oar paad lêst as it bestân dat do bewurke hast, is in faak foarkommende en pynlike oarsaak fan „de wiziging die neat”:

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

De ferzjerige is fan belang yn in mingde float. Relayôfhanneling, punchgedrach en akseptearre konfiguraasjesleutels binne net identyk oer útjeften hinne, gean der dus net fan út dat in âldere build in seksje begrypt wêr’t er net foar skreaun is. Set de hosts op deselde minor-rige, fier dan nebula -test -config /etc/nebula/config.yml op elke host út en fergelykje de útfier foardat do in transport debuggest dat de koade net implementearret.

Skeakel de trochstjoerrol yn op de relayhost

De relayrol is ien flagge op de trochstjoerende host, en stiet los fan it wêzen fan in lighthouse. In host mei ûntdekking oan en relaytrochstjoering út bliuwt allinnich in ûntdekkingsstsjinst. Op de relay:

relay:
  am_relay: true

Dy flagge ferklearret in bedoeling; hy makket neat berikber. In relay moat fan beide peers ôf berikber wêze, wat yn de praktyk in iepenbier adres betsjut, ynkommende UDP op de Nebula-poarte iepen yn de hostfirewall en yn elke cloudfeiligensgroep, en gjin dûbele NAT derfoar. Kontrolearje de lústerjende socket en sjoch dan oft de pakketten fan de peer oankomme:

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

Twa grinzen sparje letter tiid. In relay is net fia in oare relay berikber, dus in keatling relaynammen yn in konfiguraasje ferfangt gjin brûkber paad nei de trochstjoerende host. En in relay stjoert pakketten troch; hy jout gjin tastimming, de ynkommende regels fan it doel bepale noch altyd oft de trochstjoerde stream tastien is. De rol en har easken steane yn de dokumintaasje oer relaykonfiguraasje.

Kundigje de relay oan fan it doel ôf, net fan de klant

Dit is de omkearing dy’t de measte oeren fret. De relaylist heart by de host dy’t do berikke wolst, want hy fertelt oare peers hokker relays brûkt wurde meie om dy host te berikken. Him op de klant sette dy’t de ferbining start, docht neat foar de rjochting dy’t de klant nedich hat:

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

Peers melde dy list tegearre mei har adressen as se har by de lighthouse melde, dus de oankundiging ferspriedt him fia de ûntdekking en net fia in direkte útwikseling. As it doel gjin lighthouse berikt, ferspriedt syn relaylist him nea en in korrekt konfigurearre relay bliuwt ledich. Dy flater liket krekt op in stikken relay en is it net.

Jou it doel in bootstrap-paad yn deselde ronde. De statyske hostkaart bûnet in Nebula-adres oan in iepenbier einpunt sadat de earste hânskodding earne hinne kin, en hy hat in ynfier foar de relay nedich as it doel trochstjoerd ferkear fan hosts akseptearje moat dy’t it net direkt berikt:

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

Lit de ferbinende peer de relay brûke

De inisjearjende kant hat syn eigen tastimming nedich. relay.use_relays stiet standert oan, dus it gefal dat it sykjen wurdich is, is in eksplisite false, faak kopiearre út in sjabloan skreaun foardat de relayfunksje bestie of efterlitten troch in eardere besykjen om direkte paden ôf te twinghen:

relay:
  use_relays: true

Tastimming oan dizze kant is net de iennige poarte. De ynkommende regels fan it doel jilde noch altyd foar it trochstjoerde pakket, en de boarne dêr’t se mei ferlike wurde is de identiteit binnen de tunnel en net it adres fan de relay sels. As de trochstjoerde hânskodding foltôge is en de applikaasje noch altyd mislearret, lês dan it logboek fan it doel foar de boarne dy’t it fêstleine hat foardat do in regel opnij skriuwst.

NAT-traversalynstellings wurkje hjir allegear mei tegearre. punchy.punch helpt twa peers in direkt paad te iepenjen, en as dat slagget is der gjin relayferkear te sjen; dat is súkses, gjin ûntbrekkende relay. In pear dat mei tuskenskoften wurket, betsjut meast dat it punchjen soms slagget, test dat pear dus ferskate kearen ynstee fan út ien besykjen in konklúzje te lûken.

Ferifiearje mei it pear dat mislearre en laad dan opnij

Test de twa hosts dy’t echt mislearre, mei de applikaasje dy’t se nedich hawwe. In slagge ping fan dyn wurkstasjon nei de tsjinst fan de relay sels bewiist neat oer trochstjoering tusken twa oare peers, en it is de meast foarkommende falske positive yn hiel dizze proseduere.

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

Laad opnij ynstee fan opnij te starten, en befêstigje dat it draaiende proses it bestân opnommen hat dat do bewurke hast. In werstart brekt elke tunnel ôf en makket de folgjende test hurder te lêzen, wylst in SIGHUP it proses hâldt en it de konfiguraasje opnij ynlade lit:

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

systemctl reload wurket allinnich as de lokale unit ExecReload definiearret, en de unit dy’t mei it projekt meikomt docht dat net, dus systemctl kill -s HUP is de stap dy’t op in standertynstallaasje slagget. Lês nei it opladen it journaal foar it konfiguraasjepaad dat it proses iepene hat, sadat do witst dat it nije bestân lêzen is en net dat dêr’t do fan oannaamst dat it laden wie.

Relayynstellings en NAT-punching wurkje beide op it paad; gjin fan beide wurket op de identiteit. As it pear syn hânskodding noch altyd mist as am_relay, relays en use_relays yn de draaiende konfiguraasje befêstige binne, kontrolearje dan oft beide hosts sertifikaten toane dy’t útjûn binne foar de nammen dêr’t se mei konfigurearre binne en oft de CA oan beide kanten deselde is. Hâld de sertifikaat- en firewallkonfiguraasje fêst wylst do ien transportynstelling tagelyk feroarest, want in sertifikaatwiziging en in relaywiziging yn deselde test fertelle dy neat oer hokker fan de twa de hânskodding ferpleatst hat. In namme- of CA-ôfwiking mislearret op itselde plak as in relay dy’t nea fûn waard, en dêrom heart dizze tsjinkontrôle yn deselde ronde.

Befêstigje dêrnei dat elke ferklearring yn it bestân stiet dêr’t er by heart:

  • am_relay: true op de trochstjoerende host, en dy host fan beide kanten ôf fia UDP berikber.
  • relays: mei it Nebula-adres fan dy host op it doel.
  • use_relays: true op de peer dy’t de ferbining start.
  • Ynkommende regels op it doel dy’t de echte boarne nei de paadwiziging noch altyd tastean.

Relatearre artikelen