Nebula-relajso agordita sed neuzata: tri agordoj por kontroli

Vi aldonis relajsan gastiganton, metis ĝian Nebula-adreson en agordon, kaj la du partneroj ankoraŭ ne interparolas. Tio okazas ĉar relajsa vojo bezonas tri apartajn deklarojn, kiuj devas kongrui, kaj nur unu el ili troviĝas sur la maŝino, kiun vi verŝajne redaktis. Mi jam dufoje postkuris ĉi tion: unufoje la plusenda gastiganto neniam ricevis la relajsan rolon, kaj unufoje la agordoj estis skribitaj sur la malĝusta flanko de la konekto. La sekva sinsekvo kontrolas la rolon, la anoncon kaj la permeson en tiu ordo, kaj ĉiu paŝo havas komandon, kiu diras al vi, ĉu daŭrigi.

Mapu la tri rolojn antaŭ ol redakti agordon

Nebula donas al ĉiu gastiganto taskon, kaj la taskoj ne herediĝas. Lumturo respondas demandojn kiel kie estas ĉi tiu partnero, por ke gastigantoj povu trovi unu la alian. Relajso plusendas trafikon inter du partneroj, kiuj ne havas funkciantan rektan vojon. Ordinara gastiganto faras nek unu nek la alian. La tri agordoj, kiuj gravas, troviĝas sur tri malsamaj maŝinoj, kaj tial klienta agordo, kiu ŝajnas kompleta, povas lasi ambaŭ partnerojn atendantaj.

# 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

Unu simptomo apartigas la du klasojn de paneo. Se ambaŭ partneroj listigas unu la alian kaj la protokolo montras manpremajn provojn, kiuj neniam finiĝas, la malkovro funkcias kaj la datenvojo estas blokata de NAT aŭ de fajromuro. Se partnero tute ne ekscias la adreson de la alia, la problemo estas en la lumturo aŭ en ĝia statika gastiganta mapo, kaj relajsaj agordoj ne povas ripari tion.

Konfirmu, kiun agordon ĉiu gastiganto efektive ŝargis, antaŭ ol ŝanĝi ion alian. Unuo, kiu legas alian vojon ol la dosiero, kiun vi redaktis, estas ofta kaj hontiga kaŭzo de „la ŝanĝo faris nenion”:

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

La versia linio gravas en miksita aro. Relajsa traktado, puncha konduto kaj akceptitaj agordaj ŝlosiloj ne identas inter eldonoj, do ne supozu, ke pli malnova konstruo komprenas sekcion, por kiu ĝi ne estis verkita. Vicigu la gastigantojn sur la sama minora serio, poste rulu nebula -test -config /etc/nebula/config.yml sur ĉiu gastiganto kaj komparu la eligon antaŭ ol sencimigi transporton, kiun la kodo ne realigas.

Ŝaltu la plusendan rolon sur la relajsa gastiganto

La relajsa rolo estas unu flago sur la plusenda gastiganto, kaj ĝi estas aparta de esti lumturo. Gastiganto kun malkovro ŝaltita kaj relajsa plusendado malŝaltita restas nur malkovra servo. Sur la relajso:

relay:
  am_relay: true

Tiu flago deklaras intencon; ĝi ne kreas atingeblon. Relajso devas esti atingebla de ambaŭ partneroj, kio praktike signifas publikan adreson, envenan UDP sur la Nebula-pordo malfermita en la gastiganta fajromuro kaj en ajna nuba sekureca grupo, kaj neniun duoblan NAT antaŭ ĝi. Kontrolu la aŭskultantan soketon kaj poste observu, ĉu la pakaĵoj de la partnero alvenas:

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

Du limoj ŝparas tempon poste. Relajso ne estas atingebla tra alia relajso, do ĉeno de relajsaj nomoj en agordo ne anstataŭas uzeblan vojon al la plusenda gastiganto. Kaj relajso plusendas pakaĵojn; ĝi ne donas permeson, la envenaj reguloj de la celo ankoraŭ decidas, ĉu la plusendita fluo estas permesita. La rolo kaj ĝiaj postuloj estas en la dokumentaro pri relajsa agordo.

Anoncu la relajson de la celo, ne de la kliento

Jen la inversigo, kiu konsumas la plej multajn horojn. La relajsa listo apartenas al la gastiganto, kiun vi provas atingi, ĉar ĝi diras al aliaj partneroj, kiuj relajsoj rajtas esti uzataj por atingi tiun gastiganton. Meti ĝin sur la klienton, kiu komencas la konekton, faras nenion por la direkto, kiun la kliento bezonas:

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

Partneroj raportas tiun liston kune kun siaj adresoj, kiam ili sin anoncas ĉe la lumturo, do la anonco disvastiĝas per la malkovro kaj ne per rekta interŝanĝo. Se la celo ne atingas lumturon, ĝia relajsa listo neniam disvastiĝas kaj ĝuste agordita relajso restas senokupa. Tiu paneo aspektas ekzakte kiel difektita relajso kaj ne estas tio.

Donu al la celo startan vojon en la sama paŝo. La statika gastiganta mapo ligas Nebula-adreson al publika finpunkto, por ke la unua manpremo havu kien iri, kaj ĝi bezonas entajpon por la relajso, se la celo devas akcepti plusenditan trafikon de gastigantoj, kiujn ĝi ne povas atingi rekte:

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

Lasu la konektantan partneron uzi la relajson

La komencanta flanko bezonas sian propran permeson. relay.use_relays estas ŝaltita defaŭlte, do la kazo inda serĉi estas eksplicita false, ofte kopiita el ŝablono verkita antaŭ ol la relajsa funkcio ekzistis aŭ lasita de pli frua provo devigi rektajn vojojn:

relay:
  use_relays: true

Permeso sur ĉi tiu flanko ne estas la sola pordego. La envenaj reguloj de la celo ankoraŭ validas por la plusendita pakaĵo, kaj la fonto, kun kiu ili estas komparataj, estas la identeco ene de la tunelo kaj ne la adreso de la relajso mem. Kiam la plusendita manpremo finiĝas kaj la aplikaĵo ankoraŭ malsukcesas, legu la protokolon de la celo por la fonto, kiun ĝi registris, antaŭ ol reverki regulon.

NAT-transiraj agordoj interagas kun ĉio ĉi. punchy.punch helpas du partnerojn malfermi rektan vojon, kaj kiam ĝi sukcesas, estas neniu relajsa trafiko observebla; tio estas sukceso, ne mankanta relajso. Paro, kiu funkcias intermitente, kutime signifas, ke la punchado sukcesas nur foje, do testu tiun paron plurfoje anstataŭ tiri konkludon el unu provo.

Kontrolu per la paro, kiu malsukcesis, kaj poste reŝargu

Testu la du gastigantojn, kiuj efektive malsukcesis, kun la aplikaĵo, kiun ili bezonas. Sukcesa ping de via laborejo al la servo de la relajso mem pruvas nenion pri plusendado inter du aliaj partneroj, kaj ĝi estas la plej ofta falsa pozitivo en ĉi tiu tuta procedo.

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

Reŝargu anstataŭ restartigi, kaj konfirmu, ke la kuranta procezo prenis la dosieron, kiun vi redaktis. Restartigo deŝiras ĉiun tunelon kaj malfaciligas legi la sekvan teston, dum SIGHUP konservas la procezon kaj igas ĝin relegi la agordon:

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

systemctl reload funkcias nur kiam la loka unuo difinas ExecReload, kaj la unuo liverata kun la projekto ne faras tion, do systemctl kill -s HUP estas la paŝo, kiu sukcesas en norma instalo. Post la reŝargo legu la ĵurnalon por la agorda vojo, kiun la procezo malfermis, por ke vi sciu, ke la nova dosiero estis legita kaj ne tiu, kiun vi supozis ŝargita.

Relajsaj agordoj kaj NAT-punchado ambaŭ agas sur la vojo; nek agas sur la identeco. Se la paro ankoraŭ malsukcesas sian manpremon, post kiam am_relay, relays kaj use_relays estas konfirmitaj en la kuranta agordo, kontrolu, ke ambaŭ gastigantoj prezentas atestilojn eldonitajn por la nomoj, kun kiuj ili estas agorditaj, kaj ke la CA estas la sama sur ambaŭ flankoj. Tenu la atestilan kaj fajromuran agordojn fiksaj dum vi ŝanĝas unu transportan agordon samtempe, ĉar atestila ŝanĝo kaj relajsa ŝanĝo en la sama testo diras al vi nenion pri tio, kiu el ili movis la manpremon. Nekongruo de nomo aŭ CA malsukcesas en la sama loko kiel relajso, kiu neniam estis trovita, kaj tial ĉi tiu kontraŭkontrolo apartenas al la sama paŝo.

Poste konfirmu, ke ĉiu deklaro staras en la dosiero al kiu ĝi apartenas:

• am_relay: true sur la plusenda gastiganto, kaj tiu gastiganto atingebla per UDP de ambaŭ flankoj.
• relays: nomante la Nebula-adreson de tiu gastiganto sur la celo.
• use_relays: true sur la partnero, kiu komencas la konekton.
• Envenaj reguloj sur la celo, kiuj ankoraŭ permesas la realan fonton post la voja ŝanĝo.