Nebula-relay on seadistatud, aga kasutamata: kolm seadet, mida kontrollida

Sa lisasid relay-hosti, panid selle Nebula-aadressi seadistusse ja kaks partnerit ei räägi ikkagi omavahel. See juhtub seetõttu, et relay-teek vajab kolme eraldi väidet, mis peavad kokku sobima, ja ainult üks neist asub masinas, mida sa tõenäoliselt muutsid. Olen seda kaks korda jälitanud: ühel korral polnud edastus-hostile kunagi relay-rolli antud, ja teisel korral olid seaded kirjutatud ühenduse valele poolele. Allpool olev järjestus kontrollib rolli, teadaande ja loa selles järjekorras ning igal sammul on käsk, mis ütleb, kas jätkata.

Kaardista kolm rolli enne seadistuse muutmist

Nebula annab igale hostile ülesande ja ülesanded ei pärandu. Lighthouse vastab küsimustele nagu kus see partner on, et hostid leiaksid üksteist. Relay edastab liiklust kahe partneri vahel, kellel pole toimivat otseteekonda. Tavaline host ei tee kumbagi. Kolm olulist seadet asuvad kolmel erineval masinal ja seetõttu võib täielikuna näiv kliendiseadistus jätta mõlemad partnerid ootama.

# 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

Üks sümptom eraldab kaks veaklassi. Kui mõlemad partnerid loetlevad üksteist ja logi näitab kätlemiskatseid, mis kunagi ei lõpe, töötab avastus ja andmetee on blokeeritud NAT-i või tulemüüri poolt. Kui partner ei saa teise aadressist üldse teada, on probleem lighthouses või selle staatilises hostikaardis ning relay-seaded ei saa seda parandada.

Kinnita, millise seadistuse iga host tegelikult laadis, enne kui midagi muud muudad. Unit, mis loeb teist teed kui sinu muudetud fail, on tavaline ja piinlik põhjus, miks „muudatus ei teinud midagi”:

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

Versioonirida loeb segases pargis. Relay-käsitlus, punch-käitumine ja aktsepteeritud seadistusvõtmed ei ole väljaannete lõikes identsed, seega ära eelda, et vanem build mõistab jaotist, mille jaoks seda ei kirjutatud. Sea hostid samale minor-seeriale, käivita seejärel nebula -test -config /etc/nebula/config.yml igal hostil ja võrdle väljundit enne, kui hakkad siluma transporti, mida kood ei rakenda.

Luba edastusroll relay-hostil

Relay-roll on üks lipp edastus-hostil ja see on lighthousena olemisest eraldi. Host, millel avastus on sees ja relay-edastus väljas, on endiselt ainult avastusteenus. Relayl:

relay:
  am_relay: true

See lipp deklareerib kavatsuse; see ei loo kättesaadavust. Relay peab olema kättesaadav mõlemast partnerist, mis tähendab praktikas avalikku aadressi, sissetulevat UDP-d Nebula pordil, mis on avatud hosti tulemüüris ja igas pilve turvagrupis, ning mitte ühtegi topelt-NAT-i selle ees. Kontrolli kuulavat socketit ja jälgi seejärel, kas partneri paketid saabuvad:

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

Kaks piiri säästavad hiljem aega. Relayle ei pääse teise relay kaudu, seega relay-nimede ahel seadistuses ei asenda edastus-hostile kasutatava tee andmist. Ja relay edastab pakette; see ei anna luba, sihtkoha enda sissetulevad reeglid otsustavad endiselt, kas edastatud voog on lubatud. Roll ja selle nõuded on kirjas relay seadistamise dokumentatsioonis.

Teata relayst sihtkohast, mitte kliendist

See on ümberpööramine, mis sööb kõige rohkem tunde. Relay-loend kuulub hostile, mida proovid kätte saada, sest see ütleb teistele partneritele, milliseid relay-sid tohib selle hosti juurde jõudmiseks kasutada. Selle panemine ühenduse avavasse klienti ei tee midagi suunas, mida klient vajab:

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

Partnerid teatavad selle loendi koos oma aadressidega, kui nad end lighthouses registreerivad, seega teade levib avastuse kaudu, mitte otsese vahetuse kaudu. Kui sihtkoht ei jõua ühegi lighthouse’ini, ei levi selle relay-loend kunagi ja õigesti seadistatud relay jääb jõude. See viga näeb täpselt välja nagu katkine relay ja ei ole seda.

Anna sihtkohale algteek samas käigus. Staatiline hostikaart seob Nebula-aadressi avaliku lõpp-punktiga, et esimesel kätlemisel oleks kuhu minna, ja see vajab relay jaoks kirjet, kui sihtkoht peab vastu võtma edastatud liiklust hostidelt, kuhu ta otse ei jõua:

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

Lase ühenduval partneril relayd kasutada

Algatajal on vaja oma luba. relay.use_relays on vaikimisi sees, seega otsimist väärt juhtum on selgesõnaline false, sageli kopeeritud mallist, mis kirjutati enne relay-funktsiooni olemasolu, või jäetud varasemast katsest otseteid peale suruda:

relay:
  use_relays: true

Luba sellel poolel ei ole ainus värav. Sihtkoha sissetulevad reeglid kehtivad endiselt edastatud paketi kohta ja allikas, millega neid võrreldakse, on identiteet tunnelis, mitte relay enda aadress. Kui edastatud kätlemine lõpeb ja rakendus ikka ebaõnnestub, loe sihtkoha logist allikas, mille see fikseeris, enne kui reegli ümber kirjutad.

NAT-i läbimise seaded mõjutavad kõike seda. punchy.punch aitab kahel partneril otsetee avada ja kui see õnnestub, pole relay-liiklust jälgida; see on edu, mitte puuduv relay. Aeg-ajalt töötav paar tähendab tavaliselt, et punch õnnestub mõnikord, seega testi seda paari mitu korda, selle asemel et teha ühest katsest järeldus.

Kontrolli paariga, mis ebaõnnestus, ja laadi siis uuesti

Testi neid kahte hosti, mis tegelikult ebaõnnestusid, nende vajaliku rakendusega. Edukas ping sinu tööjaamast relay enda teenusesse ei tõesta midagi edastamise kohta kahe teise partneri vahel ja see on kogu selle protseduuri kõige levinum valepositiivne tulemus.

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

Laadi uuesti, selle asemel et taaskäivitada, ja kinnita, et töötav protsess võttis sinu muudetud faili. Taaskäivitamine rebib iga tunneli maha ja teeb järgmise testi raskemini loetavaks, samas kui SIGHUP hoiab protsessi alles ja paneb selle seadistuse uuesti lugema:

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

systemctl reload töötab ainult siis, kui kohalik unit määratleb ExecReloadi, ja projektiga kaasas olev unit ei tee seda, seega systemctl kill -s HUP on samm, mis standardpaigalduses õnnestub. Pärast uuestilaadimist loe journalist seadistustee, mille protsess avas, et teaksid, et uut faili loeti, mitte seda, mida arvasid laadituks.

Relay-seaded ja NAT-punch mõjutavad mõlemad teed; kumbki ei mõjuta identiteeti. Kui paar ebaõnnestub kätlemises endiselt, kui am_relay, relays ja use_relays on töötavas seadistuses kinnitatud, kontrolli, et mõlemad hostid esitavad sertifikaadid, mis on välja antud nimedele, millega nad on seadistatud, ja et CA on mõlemal poolel sama. Hoia sertifikaadi- ja tulemüürisiseseadistus muutumatuna, kui muudet korraga ühte transpordiseadet, sest sertifikaadimuudatus ja relay muudatus samas testis ei ütle sulle midagi selle kohta, kumb neist kätlemist liigutas. Nime- või CA-erinevus ebaõnnestub samas kohas nagu relay, mida kunagi ei leitud, ja seetõttu kuulub see vastukontroll samasse käiku.

Seejärel kinnita, et iga väide on failis, kuhu see kuulub:

• am_relay: true edastus-hostil ja see host on mõlemalt poolt UDP kaudu kättesaadav.
• relays: selle hosti Nebula-aadressiga sihtkohas.
• use_relays: true partneril, kes ühenduse avab.
• Sihtkoha sissetulevad reeglid, mis lubavad pärast teemuudatust endiselt tegelikku allikat.