Nebula: an saita hanyar relay amma ba a yi amfani da ita — saituna uku da za a duba

Ka ƙara host ɗin relay, ka saka adireshin Nebula ɗinsa a cikin config, amma peers ɗin biyu har yanzu ba sa magana. Wannan yana faruwa ne domin hanyar relay tana buƙatar bayanai uku daban-daban su daidaita, kuma ɗaya ne kawai daga cikinsu yake kan injin da wataƙila ka gyara. Na bi wannan sau biyu: wani lokaci ba a taɓa ba host ɗin turawa matsayin relay ba, wani lokacin kuma an rubuta saitunan a gefen da bai dace ba na haɗin. Jerin da ke ƙasa yana duba matsayi, sanarwa da izini a wannan tsari, kuma kowane mataki yana da umarni da ke gaya maka ko za ka ci gaba.

Yi taswirar matsayai uku kafin ka gyara config

Nebula tana ba kowane host aiki, kuma ayyukan ba a gado suke ba. Hasken teku yana amsa tambayoyin 'ina wannan peer yake' domin hosts su sami juna. Relay yana tura zirga-zirga tsakanin peers biyu waɗanda ba su da hanyar kai tsaye mai aiki. Talakawan host ba ya yin ɗaya daga cikinsu. Saitunan uku masu muhimmanci suna kan injuna uku daban-daban, shi ya sa config ɗin client da ya yi kama da cikakke zai iya barin peers ɗin biyu suna jira.

# 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

Alama ɗaya tana raba nau'ikan gazawa biyu. Idan peers ɗin biyu suna lissafa juna kuma log ɗin yana nuna ƙoƙarin handshake da ba sa ƙarewa, gano yana aiki kuma hanyar data ta toshe ta NAT ko firewall. Idan peer bai taɓa sanin adireshin ɗayan ba, hasken teku ko taswirar hosts ɗin sa na tsaye ne matsalar, kuma saitunan relay ba za su iya gyara hakan ba.

Tabbatar da wane config kowane host ya loda a zahiri kafin ka gyara wani abu. Unit ɗin da ke karanta wata hanya dabam da fayil ɗin da ka gyara shi ne sanannen kuma abin kunya dalilin 'canjin bai yi komai ba':

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

Layin sigar yana da muhimmanci a cikin garken da ya haɗu. Gudanar da relay, halin huɗa da maɓallan config da ake karɓa ba su daidaita a tsakanin fitowa ba, don haka kada ka ɗauka cewa tsohon build yana fahimtar sashe da ba a rubuta masa ba. Daidaita hosts ɗin a kan ƙaramin jerin guda ɗaya, sannan ka gudanar da nebula -test -config /etc/nebula/config.yml a kowane host kuma ka kwatanta fitarwa kafin ka yi debug ɗin hanyar jigilar da lambar ba ta aiwatarwa.

Kunna matsayin turawa a host ɗin relay

Matsayin relay tuta ɗaya ce a kan host ɗin turawa, kuma ya bambanta da zama hasken teku. Host ɗin da aka kunna gano a cikinsa kuma aka kashe turawar relay har yanzu sabis ne na gano kawai. A kan relay:

relay:
  am_relay: true

Wannan tuta tana bayyana niyya; ba ta haifar da isarsu ba. Dole relay ya isa daga peers ɗin biyu, wanda a aikace yake nufin adireshin jama'a, UDP mai shigowa a tashar Nebula a buɗe a firewall ɗin host da a kowane rukunin tsaro na girgije, kuma babu NAT mai ninki biyu a gabansa. Duba socket ɗin sauraro, sannan ka lura da isowar fakitin peer:

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

Iyakoki biyu suna ceton lokaci daga baya. Ba za a isa relay ta wani relay ba, don haka jerin sunayen relay a cikin config ba ya maye gurbin ba host ɗin turawa hanyar da za a iya amfani da ita. Kuma relay yana tura fakiti; ba ya ba da izini, don haka dokokin shigowa na makoma da kansu ne ke yanke shawarar ko an yarda da kwararar da aka tura ta relay. An bayyana matsayin da bukatunsa a cikin takardun saitin relay.

Yi sanarwar relay daga makoma, ba daga client ba

Wannan ita ce juyar da ke cinye sa'o'i mafi yawa. Jerin relay na kan host ɗin da kake ƙoƙarin isa, domin yana gaya wa sauran peers waɗanne relay za a iya amfani da su don isa wannan host. Saka shi a kan client ɗin da ke fara haɗin ba ya yin komai ga alkiblar da client ke buƙata:

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

Peers suna ba da wannan jerin tare da adireshinsu sa'ad da suka yi check-in da hasken teku, don haka sanarwar tana yaɗuwa ta hanyar ganowa maimakon musayar kai tsaye. Idan makoma ba za ta iya isa hasken teku ba, jerin relay ɗinta ba ya taɓa yaɗuwa kuma relay ɗin da aka saita daidai ya kasance a kwance. Wannan gazawar tana kama da relay ɗin da ya lalace sosai kuma ba haka ba ne.

Ba makoma hanyar farawa a wannan zagayen. Taswirar hosts ɗin tsaye tana ɗaure adireshin Nebula da wata maƙura ta jama'a domin handshake ɗin farko ya sami inda zai je, kuma tana buƙatar shigarwa don relay idan makoma za ta karɓi zirga-zirgar da aka tura ta relay daga hosts ɗin da ba za ta iya isa kai tsaye ba:

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

Bar peer ɗin da ke haɗawa ya yi amfani da relay

Bangaren da ke farawa yana buƙatar izininsa. relay.use_relays yana kunne ta tsohuwa, don haka al'amarin da ya cancanci bincike shi ne false bayyananne, wanda galibi ana kwafa shi daga samfurin da aka rubuta kafin fasalin relay ya wanzu ko kuma an bar shi daga wani ƙoƙari na baya na tilasta hanyoyin kai tsaye:

relay:
  use_relays: true

Izinin a wannan gefen ba shi ne ƙofar kaɗai ba. Dokokin shigowa na makoma har yanzu suna aiki a kan fakitin da aka tura ta relay, kuma tushen da suke daidaitawa da shi shi ne asalin da ke cikin rami ba adireshin relay ɗin kansa ba. Sa'ad da handshake ɗin da aka tura ta relay ya kammala kuma manhajar har yanzu ta kasa, karanta log ɗin makoma don tushen da ta yi rikodin kafin ka sake rubuta doka.

Saitunan tsallake NAT suna mu'amala da duk wannan. punchy.punch yana taimaka wa peers biyu su buɗe hanyar kai tsaye, kuma idan ya yi nasara babu zirga-zirgar relay da za a lura da ita; wannan nasara ce, ba relay ɗin da ya ɓace ba. Ma'auratan da ke aiki lokaci-lokaci yawanci suna nufin huɗa tana yin nasara wani lokaci, don haka gwada wannan ma'auratan sau da yawa maimakon yanke hukunci daga ƙoƙari ɗaya.

Tabbatar da ma'auratan da suka kasa, sannan sake loda

Gwada hosts ɗin biyu da suka kasa a zahiri, da manhajar da suke buƙata. ping ɗin da ya yi nasara daga wurin aikinka zuwa sabis ɗin relay ɗin kansa ba ya tabbatar da komai game da turawa tsakanin wasu peers biyu, kuma shi ne mafi yawan sakamakon ƙarya a cikin dukan wannan hanya.

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

Sake loda maimakon sake farawa, kuma tabbatar da cewa tsarin da ke gudana ya karɓi fayil ɗin da ka gyara. Sake farawa yana rushe kowane rami kuma yana sa gwajin na gaba ya fi wuyar karantawa, yayin da SIGHUP ke riƙe tsarin kuma yana sa ya sake karanta saitin:

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

systemctl reload yana aiki ne kawai lokacin da unit ɗin gida ya ayyana ExecReload, kuma unit ɗin da ke zuwa da aikin ba ya yin haka, don haka systemctl kill -s HUP shi ne matakin da ke yin nasara a kan shigarwa ta yau da kullum. Bayan sake lodawa, karanta journal ɗin don hanyar config ɗin da tsarin ya buɗe, domin ka san an karanta sabon fayil ɗin ba wanda ka zata ba.

Saitunan relay da huɗar NAT duk suna aiki a kan hanya; babu ɗayansu da ke aiki a kan asali. Idan ma'auratan har yanzu sun kasa handshake ɗinsu bayan an tabbatar da am_relay, relays da use_relays a cikin config ɗin da ke gudana, duba cewa hosts ɗin biyu suna gabatar da takaddun shaida da aka bayar don sunayen da aka saita su da su kuma CA ɗin ɗaya ne a ɓangarorin biyu. Riƙe takardar shaida da saitin firewall a tsaye yayin da kake canza saitin jigila ɗaya a lokaci ɗaya, domin gyaran takardar shaida da gyaran relay da suka faɗi a gwaji ɗaya ba sa gaya maka wanne ne ya motsa handshake ɗin. Rashin daidaituwar suna ko CA yana kasa a wuri ɗaya da relay ɗin da ba a taɓa samu ba, shi ya sa wannan duba ta gaba ta ke cikin wannan zagayen.

Sannan tabbatar da kowace sanarwa tana cikin fayil ɗin da ta dace da shi:

• am_relay: true a kan host ɗin turawa, kuma wannan host ɗin ya isa ta UDP daga ɓangarorin biyu.
• relays: yana ambaton adireshin Nebula na wannan host a makoma.
• use_relays: true a kan peer ɗin da ke fara haɗin.
• Dokokin shigowa a makoma har yanzu suna barin ainihin tushe bayan hanyar ta canza.