Nebula: releja është konfiguruar por e papërdorur — tre cilësime për t'u kontrolluar

Shtuat një host rele, vendosët adresën e tij Nebula në një konfigurim, dhe të dy peer-ët ende nuk komunikojnë. Kjo ndodh sepse një rrugë rele kërkon tri deklarata të veçanta të pajtohen, dhe vetëm njëra prej tyre ndodhet në makinën që me gjasë redaktuam. E kam ndjekur këtë dy herë: një herë hosti i përcjelljes nuk i ishte dhënë kurrë roli i releut, dhe një herë cilësimet ishin shkruar në anën e gabuar të lidhjes. Sekuenca më poshtë kontrollon rolin, shpalljen dhe lejen pikërisht në atë rend, dhe çdo hap ka një komandë që ju thotë nëse duhet të vazhdoni.

Hartoni tri rolet përpara se të redaktoni një konfigurim

Nebula i jep çdo hosti një punë, dhe punët nuk trashëgohen. Fari përgjigjet pyetjeve 'ku është ky peer' që hostet të gjejnë njëri-tjetrin. Releu përcjell trafikun midis dy peer-ëve që nuk kanë një rrugë të drejtpërdrejtë funksionale. Një host i zakonshëm nuk bën asnjërën. Tri cilësimet që kanë rëndësi jetojnë në tri makina të ndryshme, prandaj një konfigurim klienti që duket i plotë mund t'i lërë të dy peer-ët në pritje.

# 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

Një simptomë ndan dy klasat e dështimit. Nëse të dy peer-ët e listojnë njëri-tjetrin dhe regjistri tregon përpjekje shtrëngimi duarsh që nuk përfundojnë kurrë, zbulimi po funksionon dhe rruga e të dhënave është bllokuar nga NAT ose nga një firewall. Nëse një peer nuk e mëson kurrë adresën e tjetrit, problemi është në far ose në hartën e tij statike të hosteve, dhe cilësimet e releut nuk mund ta rregullojnë atë.

Konfirmoni se cilin konfigurim ka ngarkuar vërtet çdo host përpara se të redaktoni çdo gjë tjetër. Një njësi që lexon një rrugë të ndryshme nga skedari që redaktuam është një shkak i zakonshëm dhe i turpshëm i 'ndryshimi nuk bëri asgjë':

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

Rreshti i versionit ka rëndësi në një flotë të përzier. Trajtimi i releut, sjellja e shpimit dhe çelësat e konfigurimit të pranuar nuk janë identikë midis versioneve, prandaj mos supozoni se një ndërtim i vjetër kupton një seksion për të cilin nuk është shkruar. Rreshtoni hostet në të njëjtën seri të vogël, pastaj ekzekutoni nebula -test -config /etc/nebula/config.yml në çdo host dhe krahasoni daljen përpara se të korrigjoni një transport që kodi nuk e zbaton.

Aktivizoni rolin e përcjelljes në hostin rele

Roli i releut është një flamur në hostin e përcjelljes, dhe është i ndarë nga të qenit far. Një host me zbulim të aktivizuar dhe përcjellje rele të çaktivizuar është ende vetëm një shërbim zbulimi. Në rele:

relay:
  am_relay: true

Ky flamur deklaron qëllimin; nuk krijon arritshmëri. Releu duhet të jetë i arritshëm nga të dy peer-ët, që në praktikë do të thotë adresë publike, UDP hyrëse në portën Nebula të hapur në firewall-in e hostit dhe në çdo grup sigurie cloud, dhe pa NAT të dyfishtë përpara tij. Kontrolloni socket-in e dëgjimit, pastaj vëzhgoni mbërritjen e paketave të peer-it:

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

Dy kufizime kursejnë kohë më vonë. Releu nuk arrihet përmes një releje tjetër, prandaj një zinxhir emrash relesh në një konfigurim nuk zëvendëson dhënien e një rruge të përdorshme hostit të përcjelljes. Dhe releu përcjell paketa; nuk jep leje, prandaj rregullat hyrëse të destinacionit vendosin ende nëse rrjedha e përcjellë lejohet. Roli dhe kërkesat e tij përshkruhen në dokumentacionin e konfigurimit të releut.

Shpallni releun nga destinacioni, jo nga klienti

Ky është përmbysja që ha më shumë orë. Lista e releve i takon hostit që po përpiqeni të arrini, sepse u tregon peer-ëve të tjerë cilat rele mund të përdoren për të arritur atë host. Vendosja e saj në klientin që nis lidhjen nuk bën asgjë për drejtimin që i duhet klientit:

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

Peer-ët e raportojnë atë listë së bashku me adresat e tyre kur regjistrohen te fari, prandaj shpallja përhapet përmes zbulimit dhe jo përmes shkëmbimit të drejtpërdrejtë. Nëse destinacioni nuk mund të arrijë një far, lista e tij e releve nuk përhapet kurrë dhe një rele i konfiguruar saktë mbetet i papunë. Ai dështim duket saktësisht si një rele i prishur dhe nuk është i tillë.

Jepini destinacionit një rrugë fillestare në të njëjtin kalim. Harta statike e hosteve lidh një adresë Nebula me një pikë fundore publike që shtrëngimi i parë i duarve të ketë ku të shkojë, dhe i duhet një hyrje për releun nëse destinacioni do të pranojë trafik të përcjellë nga hoste që nuk mund t'i arrijë drejtpërdrejt:

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

Lejoni peer-in lidhës të përdorë releun

Ana nisëse ka nevojë për lejen e vet. relay.use_relays është i aktivizuar si parazgjedhje, prandaj rasti që ia vlen të kërkohet është një false e qartë, shpesh e kopjuar nga një shabllon i shkruar përpara se të ekzistonte funksioni i releut ose e mbetur nga një përpjekje e mëparshme për të imponuar rrugë të drejtpërdrejta:

relay:
  use_relays: true

Leja në këtë anë nuk është porta e vetme. Rregullat hyrëse të destinacionit vlejnë ende për paketën e përcjellë, dhe burimi me të cilin përputhen është identiteti brenda tunelit dhe jo adresa e vetë releut. Kur shtrëngimi i përcjellë përfundon dhe aplikacioni ende dështon, lexoni regjistrin e destinacionit për burimin që regjistroi përpara se të rishkruani një rregull.

Cilësimet e kalimit të NAT ndërveprojnë me të gjitha këto. punchy.punch ndihmon dy peer-ë të hapin një rrugë të drejtpërdrejtë, dhe kur kjo funksionon nuk ka trafik rele për të vëzhguar; ky është sukses, jo një rele që mungon. Një çift që punon me ndërprerje zakonisht do të thotë se shpimi ka sukses ndonjëherë, prandaj provoni atë çift disa herë në vend që të nxirrni përfundim nga një përpjekje.

Verifikoni me çiftin që dështoi, pastaj ringarkoni

Provoni dy hostet që dështuan vërtet, me aplikacionin që u nevojitet. Një ping i suksesshëm nga stacioni juaj i punës në shërbimin e vetë releut nuk provon asgjë për përcjelljen midis dy peer-ëve të tjerë, dhe ky është pozitivi i rremë më i zakonshëm në të gjithë këtë procedurë.

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

Ringarkoni në vend që të rinisni, dhe konfirmoni që procesi që po ekzekutohet e ka marrë skedarin që redaktuam. Rinisja i shemb të gjitha tunelet dhe e bën testin tjetër më të vështirë për t'u lexuar, ndërsa SIGHUP e mban procesin dhe e detyron të rilexojë konfigurimin:

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

systemctl reload funksionon vetëm kur njësia lokale përcakton ExecReload, dhe njësia që vjen me projektin nuk e bën këtë, prandaj hapi që ka sukses në një instalim standard është systemctl kill -s HUP. Pas ringarkimit lexoni regjistrin për rrugën e konfigurimit që hapi procesi, që të dini se është lexuar skedari i ri dhe jo ai që supozuat.

Cilësimet e releut dhe shpimi i NAT veprojnë të dyja mbi rrugën; asnjëra nuk vepron mbi identitetin. Nëse çifti ende dështon në shtrëngimin e duarve pasi am_relay, relays dhe use_relays janë konfirmuar në konfigurimin që ekzekutohet, kontrolloni që të dy hostet paraqesin certifikata të lëshuara për emrat me të cilët janë konfiguruar dhe që CA është i njëjtë në të dy anët. Mbani certifikatën dhe konfigurimin e firewall-it të pandryshuar ndërsa ndryshoni një cilësim transporti në një kohë, sepse një redaktim certifikate dhe një redaktim rele që bien në të njëjtin test nuk ju thonë se cili e lëvizi shtrëngimin e duarve. Një mospërputhje emri ose CA dështon në të njëjtin vend ku dështon një rele që nuk u gjet kurrë, prandaj ky kontroll kundër i përket të njëjtit kalim.

Pastaj konfirmoni që çdo deklaratë qëndron në skedarin të cilit i përket:

• am_relay: true në hostin e përcjelljes, dhe ai host i arritshëm me UDP nga të dy anët.
• relays: që emërton adresën Nebula të atij hosti në destinacion.
• use_relays: true në peer-in që nis lidhjen.
• Rregullat hyrëse në destinacion lejojnë ende burimin e vërtetë pasi rruga ndryshon.