Releu Nebula configurat, dar neutilizat: trei setări de verificat

Ai adăugat o gazdă de releu, i-ai pus adresa Nebula într-o configurație, iar cele două perechi tot nu comunică. Asta se întâmplă pentru că o cale prin releu are nevoie de trei declarații separate care trebuie să fie de acord, iar doar una dintre ele se află pe mașina pe care probabil ai editat-o. Am urmărit asta de două ori: o dată gazda de redirecționare nu primise niciodată rolul de releu, și o dată setările erau scrise pe partea greșită a conexiunii. Secvența de mai jos verifică rolul, anunțul și permisiunea în această ordine, iar fiecare pas are o comandă care îți spune dacă să continui.

Cartografiază cele trei roluri înainte să editezi o configurație

Nebula dă fiecărei gazde o sarcină, iar sarcinile nu se moștenesc. Un lighthouse răspunde la întrebări de tipul unde este acest partener, ca gazdele să se poată găsi. Un releu redirecționează trafic între doi parteneri care nu au o cale directă funcțională. O gazdă obișnuită nu face nici una, nici alta. Cele trei setări care contează stau pe trei mașini diferite, și de aceea o configurație de client care pare completă poate lăsa ambele perechi în așteptare.

# 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

Un singur simptom separă cele două clase de eșec. Dacă ambele perechi se listează reciproc și jurnalul arată încercări de handshake care nu se termină niciodată, descoperirea funcționează, iar calea de date este blocată de NAT sau de un firewall. Dacă o pereche nu află deloc adresa celeilalte, problema este în lighthouse sau în harta statică de gazde a acestuia, iar setările de releu nu pot repara asta.

Confirmă ce configurație a încărcat efectiv fiecare gazdă înainte să schimbi orice altceva. O unitate care citește altă cale decât fișierul pe care l-ai editat este o cauză comună și jenantă a faptului că „schimbarea nu a făcut nimic”:

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

Linia de versiune contează într-o flotă mixtă. Tratarea releelor, comportamentul de punching și cheile de configurare acceptate nu sunt identice între versiuni, așa că nu presupune că o compilare mai veche înțelege o secțiune pentru care nu a fost scrisă. Aliniază gazdele pe aceeași serie minor, rulează apoi nebula -test -config /etc/nebula/config.yml pe fiecare gazdă și compară ieșirea înainte să depanezi un transport pe care codul nu îl implementează.

Activează rolul de redirecționare pe gazda de releu

Rolul de releu este un singur indicator pe gazda de redirecționare și este separat de a fi lighthouse. O gazdă cu descoperirea activată și redirecționarea prin releu dezactivată rămâne doar un serviciu de descoperire. Pe releu:

relay:
  am_relay: true

Acest indicator declară o intenție; nu creează accesibilitate. Un releu trebuie să fie accesibil din ambele perechi, ceea ce în practică înseamnă o adresă publică, UDP de intrare pe portul Nebula deschis în firewallul gazdei și în orice grup de securitate din cloud, și niciun NAT dublu în față. Verifică socketul care ascultă și apoi urmărește dacă sosesc pachetele perechii:

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

Două limite economisesc timp mai târziu. La un releu nu se ajunge printr-un alt releu, așa că un lanț de nume de relee într-o configurație nu înlocuiește o cale utilizabilă către gazda de redirecționare. Și un releu redirecționează pachete; nu acordă permisiune, regulile de intrare ale destinației decid în continuare dacă fluxul redirecționat este permis. Rolul și cerințele lui sunt descrise în documentația de configurare a releului.

Anunță releul din destinație, nu din client

Aceasta este inversarea care consumă cele mai multe ore. Lista de relee aparține gazdei pe care încerci să o atingi, pentru că le spune celorlalte perechi ce relee pot fi folosite pentru a atinge acea gazdă. Să o pui pe clientul care deschide conexiunea nu face nimic pentru direcția de care clientul are nevoie:

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

Perechile raportează acea listă împreună cu adresele lor când se prezintă la lighthouse, așa că anunțul se propagă prin descoperire, nu printr-un schimb direct. Dacă destinația nu atinge niciun lighthouse, lista ei de relee nu se răspândește niciodată, iar un releu configurat corect rămâne inactiv. Acel eșec arată exact ca un releu defect și nu este.

Dă destinației o cale de pornire în aceeași trecere. Harta statică de gazde leagă o adresă Nebula de un punct final public, ca primul handshake să aibă unde merge, și are nevoie de o intrare pentru releu dacă destinația trebuie să accepte trafic redirecționat de la gazde pe care nu le atinge direct:

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

Lasă perechea care se conectează să folosească releul

Partea care inițiază are nevoie de propria permisiune. relay.use_relays este activat implicit, așa că cazul care merită căutat este un false explicit, adesea copiat dintr-un șablon scris înainte să existe funcția de releu sau lăsat de o încercare anterioară de a forța căi directe:

relay:
  use_relays: true

Permisiunea de pe această parte nu este singura poartă. Regulile de intrare ale destinației se aplică în continuare pachetului redirecționat, iar sursa cu care sunt comparate este identitatea din interiorul tunelului, nu adresa releului însuși. Când handshake-ul redirecționat se termină și aplicația tot eșuează, citește în jurnalul destinației ce sursă a fost înregistrată înainte să rescrii o regulă.

Setările de traversare NAT interacționează cu toate acestea. punchy.punch ajută două perechi să deschidă o cale directă, iar când reușește nu există trafic de releu de observat; acesta este un succes, nu un releu lipsă. O pereche care funcționează intermitent înseamnă de obicei că punchingul reușește doar uneori, așa că testează acea pereche de mai multe ori în loc să tragi o concluzie dintr-o singură încercare.

Verifică cu perechea care a eșuat, apoi reîncarcă

Testează cele două gazde care au eșuat efectiv, cu aplicația de care au nevoie. Un ping reușit de pe stația ta de lucru către serviciul releului însuși nu dovedește nimic despre redirecționarea între alte două perechi, și este cel mai frecvent fals pozitiv din toată această procedură.

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

Reîncarcă în loc să repornești, și confirmă că procesul aflat în execuție a preluat fișierul pe care l-ai editat. O repornire dărâmă fiecare tunel și face testul următor mai greu de citit, în timp ce un SIGHUP păstrează procesul și îl face să recitească configurația:

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

systemctl reload funcționează doar când unitatea locală definește ExecReload, iar unitatea livrată cu proiectul nu o face, așa că systemctl kill -s HUP este pasul care reușește pe o instalare standard. După reîncărcare, citește în journal calea de configurare pe care a deschis-o procesul, ca să știi că a fost citit fișierul nou, nu cel pe care presupuneai că e încărcat.

Setările de releu și punchingul NAT acționează ambele asupra căii; niciuna nu acționează asupra identității. Dacă perechea tot eșuează la handshake după ce am_relay, relays și use_relays sunt confirmate în configurația în execuție, verifică dacă ambele gazde prezintă certificate emise pentru numele cu care sunt configurate și dacă CA este aceeași pe ambele părți. Ține configurația de certificate și firewall nemodificată în timp ce schimbi o singură setare de transport odată, pentru că o modificare de certificat și una de releu în același test nu îți spun care dintre ele a mișcat handshake-ul. O nepotrivire de nume sau de CA eșuează în același loc ca un releu care nu a fost găsit niciodată, și de aceea această contraverificare face parte din aceeași trecere.

Apoi confirmă că fiecare declarație se află în fișierul căruia îi aparține:

• am_relay: true pe gazda de redirecționare, și acea gazdă accesibilă prin UDP din ambele părți.
• relays: cu adresa Nebula a acelei gazde pe destinație.
• use_relays: true pe perechea care deschide conexiunea.
• Reguli de intrare pe destinație care permit în continuare sursa reală după schimbarea căii.