Nebula: relay imesanidiwa lakini haitumiki — mipangilio mitatu ya kukagua

Umeongeza hosti ya relay, umeweka anwani yake ya Nebula kwenye usanidi, na bado peer mbili hazizungumzi. Hii hutokea kwa sababu njia ya relay inahitaji taarifa tatu tofauti zikubaliane, na moja tu kati yao iko kwenye mashine ambayo pengine umeihariri. Nimeifuatilia hii mara mbili: mara moja hosti ya upelekaji haikupewa jukumu la relay kamwe, na mara nyingine mipangilio iliandikwa upande usiofaa wa muunganisho. Mfululizo ulio hapa chini hukagua jukumu, tangazo na ruhusa kwa mpangilio huo, na kila hatua ina amri inayokuambia ikiwa uendelee.

Panga majukumu matatu kabla ya kuhariri usanidi

Nebula humpa kila hosti kazi, na kazi hazirithiwi. Mnara wa taa hujibu maswali 'peer hii iko wapi' ili hosti ziweze kupatana. Relay hupeleka trafiki kati ya peer mbili ambazo hazina njia ya moja kwa moja inayofanya kazi. Hosti ya kawaida haifanyi yote mawili. Mipangilio mitatu muhimu iko kwenye mashine tatu tofauti, ndiyo sababu usanidi wa mteja unaoonekana kamili unaweza kuwaacha peer zote mbili zikisubiri.

# 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

Dalili moja hutenganisha makundi mawili ya kushindwa. Ikiwa peer zote mbili zinaorodhesha kila moja na kumbukumbu zinaonyesha majaribio ya handshake ambayo hayakamiliki kamwe, ugunduzi unafanya kazi na njia ya data imezuiwa na NAT au firewall. Ikiwa peer haijifunzi anwani ya nyingine kabisa, tatizo liko kwenye mnara wa taa au kwenye ramani yake tuli ya hosti, na mipangilio ya relay haiwezi kurekebisha hilo.

Thibitisha ni usanidi upi ambao kila hosti iliupakia kwa kweli kabla ya kuhariri kitu kingine. Kitengo kinachosoma njia tofauti na faili uliyohariri ni sababu ya kawaida na ya aibu ya 'mabadiliko hayakufanya kitu':

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

Mstari wa toleo ni muhimu katika kundi mchanganyiko. Ushughulikiaji wa relay, tabia ya kutoboa na funguo za usanidi zinazokubaliwa hazifanani kati ya matoleo, kwa hiyo usidhani kuwa build ya zamani inaelewa sehemu ambayo haikuandikiwa. Sawazisha hosti kwenye mfululizo mmoja mdogo, kisha endesha nebula -test -config /etc/nebula/config.yml kwenye kila hosti na ulinganishe matokeo kabla ya kutatua usafiri ambao msimbo hautekelezi.

Washa jukumu la upelekaji kwenye hosti ya relay

Jukumu la relay ni bendera moja kwenye hosti ya upelekaji, na ni tofauti na kuwa mnara wa taa. Hosti iliyo na ugunduzi umewashwa na upelekaji wa relay umezimwa bado ni huduma ya ugunduzi tu. Kwenye relay:

relay:
  am_relay: true

Bendera hii inatangaza nia; haitengenezi ufikivu. Relay lazima ifikike kutoka kwa peer zote mbili, ambayo kwa vitendo inamaanisha anwani ya umma, UDP inayoingia kwenye bandari ya Nebula iliyofunguliwa kwenye firewall ya hosti na kwenye kundi lolote la usalama la wingu, na hakuna NAT mbili mbele yake. Kagua socket inayosikiliza, kisha angalia kuwasili kwa pakiti za peer:

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

Mipaka miwili huokoa muda baadaye. Relay haifikiki kwa njia ya relay nyingine, kwa hiyo mnyororo wa majina ya relay kwenye usanidi haubadilishi kumpa hosti ya upelekaji njia inayoweza kutumika. Na relay hupeleka pakiti; haitoi ruhusa, kwa hiyo sheria za kuingia za lengwa bado zinaamua ikiwa mtiririko uliopitishwa unaruhusiwa. Jukumu na mahitaji yake yameelezwa katika nyaraka za usanidi wa relay.

Tangaza relay kutoka kwa lengwa, si kwa mteja

Huu ni ubadilishaji unaokula saa nyingi zaidi. Orodha ya relay ni mali ya hosti unayojaribu kufikia, kwa sababu inawaambia peer nyingine ni relay zipi zinaweza kutumika kufikia hosti hiyo. Kuiweka kwenye mteja anayeanza muunganisho hakusaidii kwa mwelekeo ambao mteja anauhitaji:

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

Peer huripoti orodha hiyo pamoja na anwani zao wanapojisajili kwenye mnara wa taa, kwa hiyo tangazo huenea kupitia ugunduzi badala ya kubadilishana moja kwa moja. Ikiwa lengwa haliwezi kufikia mnara wa taa, orodha yake ya relay haiwezi kuenea kamwe na relay iliyosanidiwa vizuri inabaki bila kazi. Kushindwa huko kunaonekana kama relay iliyovunjika kabisa na si hivyo.

Mpe lengwa njia ya kuanzia katika hatua hiyo hiyo. Ramani tuli ya hosti inaunganisha anwani ya Nebula na kituo cha mwisho cha umma ili handshake ya kwanza iwe na mahali pa kwenda, na inahitaji ingizo la relay ikiwa lengwa litakubali trafiki iliyopitishwa kutoka kwa hosti ambazo haliwezi kuzifikia moja kwa moja:

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

Ruhusu peer inayounganisha itumie relay

Upande unaoanza unahitaji ruhusa yake mwenyewe. relay.use_relays imewashwa kwa chaguo-msingi, kwa hiyo kesi inayostahili kutafutwa ni false ya wazi, ambayo mara nyingi hunakiliwa kutoka kwenye kiolezo kilichoandikwa kabla ya kipengele cha relay kuwepo au hubakia kutoka kwenye jaribio la awali la kulazimisha njia za moja kwa moja:

relay:
  use_relays: true

Ruhusa ya upande huu si lango pekee. Sheria za kuingia za lengwa bado zinatumika kwa pakiti iliyopitishwa, na chanzo wanacholinganisha ni utambulisho ndani ya handaki na si anwani ya relay yenyewe. Wakati handshake iliyopitishwa inakamilika na programu bado inashindwa, soma kumbukumbu ya lengwa kwa chanzo iliyorekodi kabla ya kuandika upya sheria.

Mipangilio ya kuvuka NAT inaingiliana na haya yote. punchy.punch husaidia peer mbili kufungua njia ya moja kwa moja, na inapofanikiwa hakuna trafiki ya relay ya kuangalia; hiyo ni mafanikio, si relay inayokosekana. Jozi inayofanya kazi mara kwa mara kwa kawaida inamaanisha kutoboa kunafanikiwa wakati mwingine, kwa hiyo jaribu jozi hiyo mara kadhaa badala ya kutoa hitimisho kutoka kwa jaribio moja.

Thibitisha na jozi iliyoshindwa, kisha pakia upya

Jaribu hosti mbili zilizoshindwa kwa kweli, pamoja na programu zinazohitaji. ping iliyofanikiwa kutoka kituo chako cha kazi hadi huduma ya relay yenyewe haithibitishi chochote kuhusu upelekaji kati ya peer nyingine mbili, na hii ni matokeo ya uongo ya kawaida zaidi katika utaratibu huu wote.

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

Pakia upya badala ya kuanzisha upya, na thibitisha kuwa mchakato unaoendelea umechukua faili uliyohariri. Kuanzisha upya huvunja kila handaki na hufanya jaribio lijalo kuwa gumu kusoma, wakati SIGHUP huweka mchakato na kuufanya usome usanidi tena:

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

systemctl reload hufanya kazi tu wakati kitengo cha ndani kinafafanua ExecReload, na kitengo kinachokuja na mradi hakifanyi hivyo, kwa hiyo hatua inayofanikiwa kwenye usakinishaji wa kawaida ni systemctl kill -s HUP. Baada ya kupakia upya soma kumbukumbu kwa njia ya usanidi iliyofunguliwa na mchakato, ili ujue faili mpya imesomwa na si ile uliyodhani.

Mipangilio ya relay na kutoboa NAT zote zinaathiri njia; hakuna inayoathiri utambulisho. Ikiwa jozi bado inashindwa handshake baada ya am_relay, relays na use_relays kuthibitishwa kwenye usanidi unaoendelea, angalia kuwa hosti zote mbili zinawasilisha vyeti vilivyotolewa kwa majina ambayo zimesanidiwa nayo na kwamba CA ni sawa pande zote mbili. Weka cheti na usanidi wa firewall bila kubadilika wakati unabadilisha mpangilio mmoja wa usafiri kwa mara moja, kwa sababu uhariri wa cheti na uhariri wa relay unaoangukia jaribio moja hautakuambia ni upi uliosogeza handshake. Kutolingana kwa jina au CA kunashindwa mahali pale pale relay ambayo haikupatikana kamwe inashindwa, kwa hiyo ukaguzi huu wa kinyume ni wa hatua hiyo hiyo.

Kisha thibitisha kuwa kila taarifa iko kwenye faili inayomhusu:

• am_relay: true kwenye hosti ya upelekaji, na hosti hiyo ifikike kwa UDP kutoka pande zote mbili.
• relays: ikitaja anwani ya Nebula ya hosti hiyo kwenye lengwa.
• use_relays: true kwenye peer inayoanza muunganisho.
• Sheria za kuingia kwenye lengwa bado zinaruhusu chanzo halisi baada ya njia kubadilika.