Nebula-relay stillt en ónotað: þrjár stillingar til að athuga

Þú bættir við relay-hýsli, settir Nebula-vistfangið þess í stillingu, og jafningjarnir tveir tala samt ekki saman. Það gerist vegna þess að relay-slóð þarf þrjár aðskildar yfirlýsingar sem verða að stemma saman, og aðeins ein þeirra er á vélinni sem þú breyttir líklega. Ég hef elt þetta tvisvar: einu sinni þar sem framsendingarhýslinu hafði aldrei verið gefið relay-hlutverkið, og einu sinni þar sem stillingarnar voru skrifaðar á ranga hlið tengingarinnar. Röðin hér að neðan athugar hlutverkið, tilkynninguna og heimildina í þeirri röð, og hvert skref hefur skipun sem segir þér hvort halda eigi áfram.

Kortlegðu hlutverkin þrjú áður en þú breytir stillingu

Nebula gefur hverju hýsli verkefni, og verkefnin erfast ekki. Lighthouse svarar spurningum á borð við hvar er þessi jafningi svo hýslar geti fundið hvert annað. Relay sendir áfram umferð milli tveggja jafningja sem hafa enga virka beina slóð. Venjulegt hýsli gerir hvorugt. Stillingarnar þrjár sem skipta máli eru á þremur mismunandi vélum, og þess vegna getur biðlara-stilling sem lítur út fyrir að vera fullkomin látið báða jafningjana bíða.

# 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 einkenni aðskilur flokka bilunarinnar tvo. Ef báðir jafningjar telja upp hvorn annan og skráin sýnir handabandstilraunir sem klárast aldrei, virkar uppgötvunin og gagnaslóðin er lokuð af NAT eða eldvegg. Ef jafningi kemst aldrei að vistfangi hins er vandamálið í lighthouse eða í kyrrstæðu hýslakortinu þess, og relay-stillingar geta ekki bætt það.

Staðfestu hvaða stillingu hvert hýsli hlaði í raun áður en þú breytir einhverju öðru. Unit sem les aðra slóð en skrána sem þú breyttir er algeng og vandræðaleg orsök þess að „breytingin gerði ekkert“:

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

Útgáfulínan skiptir máli í blönduðum hópi. Relay-meðferð, punch-hegðun og samþykktar stillingarlyklar eru ekki eins á milli útgáfa, svo ekki gera ráð fyrir að eldri bygging skilji kafla sem hún var ekki skrifuð fyrir. Stilltu hýslin á sömu minor-röð, keyrðu síðan nebula -test -config /etc/nebula/config.yml á hverju hýsli og berðu saman úttakið áður en þú kembir flutning sem kóðinn útfærir ekki.

Kveiktu á framsendingarhlutverkinu á relay-hýslinu

Relay-hlutverkið er eitt flagg á framsendingarhýslinu, og það er aðskilið frá því að vera lighthouse. Hýsli með uppgötvun kveikta og relay-framsendingu slökkt er enn bara uppgötvunarþjónusta. Á relay-inu:

relay:
  am_relay: true

Flaggið lýsir yfir áformi; það skapar enga náanleika. Relay verður að vera náanlegt frá báðum jafningjum, sem í reynd þýðir opinbert vistfang, innkomandi UDP á Nebula-gáttinni opna í eldvegg hýslsins og í hvaða öryggishópi sem er í skýinu, og ekkert tvöfalt NAT fyrir framan. Athugaðu hlustandi socketið og fylgstu síðan með því hvort pakkar jafningjans berist:

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

Tvö mörk spara tíma síðar. Ekki er hægt að ná relay í gegnum annað relay, svo keðja af relay-nöfnum í stillingu kemur ekki í staðinn fyrir nothæfa slóð að framsendingarhýslinu. Og relay sendir pakka áfram; það veitir enga heimild, innkomandi reglur áfangans ráða enn hvort leyfa megi framsendu strauminn. Hlutverkið og kröfur þess eru í skjölunum um relay-stillingu.

Tilkynntu relay frá áfanganum, ekki frá biðlaranum

Þetta er umsnúningurinn sem étur flestu klukkustundirnar. Relay-listinn tilheyrir hýslinu sem þú ert að reyna að ná, því hann segir öðrum jafningjum hvaða relay megi nota til að ná því hýsli. Að setja hann á biðlarann sem hefur sambandið gerir ekkert fyrir þá stefnu sem biðlarinn þarf:

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

Jafningjar tilkynna þann lista ásamt vistföngum sínum þegar þeir skrá sig hjá lighthouse, svo tilkynningin breiðist út um uppgötvunina og ekki um beina skipti. Ef áfanginn nær engu lighthouse breiðist relay-listinn aldrei út og rétt stillt relay situr aðgerðalaust. Sú bilun lítur nákvæmlega út eins og bilað relay og er það ekki.

Gefðu áfanganum bootstrap-slóð í sama skrefi. Kyrrstæða hýslakortið tengir Nebula-vistfang við opinberan endapunkt svo fyrsta handabandið hafi eitthvert að fara, og það þarf færslu fyrir relay ef áfanginn á að taka við framsendri umferð frá hýslum sem hann nær ekki beint:

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

Leyfðu tengjandi jafningjanum að nota relay

Upphafsaðilin þarf sína eigin heimild. relay.use_relays er á sjálfgefið, svo tilfellið sem er þess virði að leita að er skýrt false, oft afritað úr sniðmáti sem var skrifað áður en relay-eiginleikinn varð til eða skilið eftir af fyrri tilraun til að þvinga beinar slóðir:

relay:
  use_relays: true

Heimildin á þessari hlið er ekki eina hliðið. Innkomandi reglur áfangans gilda enn um framsenda pakkann, og uppsprettan sem þær eru bornar saman við er auðkennið inni í göngunum en ekki vistfang relay-sins sjálfs. Þegar framsenda handabandið klárast og forritið bilar samt, lestu skrá áfangans eftir uppsprettunni sem hann skráði áður en þú skrifar reglu upp á nýtt.

NAT-ráfstillstillingar hafa áhrif á allt þetta. punchy.punch hjálpar tveimur jafningjum að opna beina slóð, og þegar það tekst er engin relay-umferð til að sjá; það er árangur, ekki vantað relay. Par sem virkar slitrótt þýðir oftast að punch tekst stundum, svo prófaðu það par nokkrum sinnum í stað þess að draga ályktun af einni tilraun.

Sannprófaðu með parinu sem brást og hlauðu síðan inn á ný

Prófaðu hýslin tvö sem brutust í raun, með forritinu sem þau þurfa. Árangursríkt ping frá vinnustöðinni þinni á þjónustu relaysins sjálfs sannar ekkert um framsendingu milli tveggja annarra jafningja, og það er algengasta falska jákvæða niðurstaðan í allri þessari aðferð.

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

Hlaða skal inn á ný í stað þess að endurræsa, og staðfesta að keyrandi ferlið hafi tekið upp skrána sem þú breyttir. Endurræsing rífur hver göng og gerir næstu prófun erfiðari að lesa, en SIGHUP heldur ferlinu og lætur það lesa stillinguna aftur:

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

systemctl reload virkar aðeins þegar staðbundna unitið skilgreinir ExecReload, og unitið sem fylgir verkefninu gerir það ekki, svo systemctl kill -s HUP er skrefið sem tekst á venjulegri uppsetningu. Lestu journal eftir innhölunina fyrir stillingarslóðina sem ferlið opnaði, svo þú vitir að nýja skráin var lesin en ekki sú sem þú gerðir ráð fyrir að væri hlaðin.

Relay-stillingar og NAT-punching virka bæði á slóðina; hvortugt virkar á auðkennið. Ef parið bregst enn handabandi þegar am_relay, relays og use_relays eru staðfest í keyrandi stillingu, athugaðu að báðir hýslar sýni skírteini útgefin fyrir nöfnin sem þau eru stillt með og að CA sé sama á báðum hliðum. Haltu skírteina- og eldveggsstillingunni fastri á meðan þú breytir einni flutningsstillingu í einu, því skírteinabreyting og relay-breyting í sömu prófun segja þér ekkert um hvor þeirra færði handabandið. Nafna- eða CA-misræmi bregst á sama stað og relay sem fannst aldrei, og þess vegna á þessi gagnprófun heima í sama skrefi.

Staðfestu síðan að hver yfirlýsing standi í skránni sem hún tilheyrir:

• am_relay: true á framsendingarhýslinu, og það hýsli náanlegt um UDP frá báðum hliðum.
• relays: með Nebula-vistfangi þess hýslis á áfanganum.
• use_relays: true á jafningjanum sem hefur sambandið.
• Innkomandi reglur á áfanganum sem leyfa enn raunverulegu uppsprettuna eftir breytingu á slóð.