Nebula relej konfiguriran, ali neiskorišten: tri postavke za provjeru

Dodali ste host releja, njegovu Nebula adresu upisali u konfiguraciju, a dva partnera još uvijek ne razgovaraju. To se događa zato što put preko releja zahtijeva tri odvojene izjave koje se moraju slagati, a samo jedna od njih nalazi se na stroju koji ste vjerojatno uređivali. Pratio sam to dvaput: jednom host za prosljeđivanje nikada nije dobio ulogu releja, a drugi put postavke su bile zapisane na pogrešnoj strani veze. Slijed u nastavku provjerava ulogu, objavu i dopuštenje tim redom, a svaki korak ima naredbu koja vam kaže trebate li nastaviti.

Preslikajte tri uloge prije nego uredite konfiguraciju

Nebula daje svakom hostu zadatak, a zadaci se ne nasljeđuju. Lighthouse odgovara na pitanja poput gdje je ovaj partner kako bi hostovi mogli pronaći jedan drugoga. Relej prosljeđuje promet između dva partnera koji nemaju radni izravni put. Obični host ne čini ni jedno ni drugo. Tri važne postavke žive na tri različita stroja, i zato konfiguracija klijenta koja izgleda cjelovito može ostaviti oba partnera na čekanju.

# 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

Jedan simptom razdvaja dvije klase kvara. Ako oba partnera navode jedan drugoga i zapisnik pokazuje pokušaje rukovanja koji nikada ne završe, otkrivanje radi, a podatkovni put blokira NAT ili vatrozid. Ako partner uopće ne sazna adresu onoga drugoga, problem je u lighthouseu ili u njegovoj statičkoj karti hostova, a postavke releja to ne mogu popraviti.

Potvrdite koju je konfiguraciju svaki host stvarno učitao prije nego promijenite bilo što drugo. Unit koji čita drugu stazu od datoteke koju ste uredili čest je i neugodan uzrok tome da „promjena nije učinila ništa”:

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

Redak verzije važan je u miješanoj floti. Rukovanje relejima, ponašanje probijanja i prihvaćeni konfiguracijski ključevi nisu jednaki među izdanjima, zato ne pretpostavljajte da starija gradnja razumije odjeljak za koji nije napisana. Poravnajte hostove na istu manju seriju, zatim pokrenite nebula -test -config /etc/nebula/config.yml na svakom hostu i usporedite izlaz prije nego počnete otklanjati pogreške u transportu koji kôd ne implementira.

Omogućite ulogu prosljeđivanja na hostu releja

Uloga releja jedna je zastavica na hostu za prosljeđivanje i odvojena je od toga da bude lighthouse. Host s uključenim otkrivanjem i isključenim prosljeđivanjem preko releja i dalje je samo usluga otkrivanja. Na releju:

relay:
  am_relay: true

Ta zastavica izražava namjeru; ne stvara dosegljivost. Relej mora biti dosegljiv s oba partnera, što u praksi znači javnu adresu, dolazni UDP na vratima Nebula otvoren u vatrozidu hosta i u bilo kojoj sigurnosnoj grupi oblaka, i bez dvostrukog NAT-a ispred. Provjerite utičnicu koja sluša, a zatim promatrajte dolaze li paketi partnera:

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

Dva ograničenja štede vrijeme kasnije. Do releja se ne može doći preko drugog releja, zato lanac imena releja u konfiguraciji ne zamjenjuje upotrebljiv put do hosta za prosljeđivanje. I relej prosljeđuje pakete; ne daje dopuštenje, o tome je li proslijeđeni tok dopušten i dalje odlučuju vlastita dolazna pravila odredišta. Uloga i njezini zahtjevi opisani su u dokumentaciji o konfiguraciji releja.

Objavite relej s odredišta, ne s klijenta

To je obrat koji pojede najviše sati. Popis releja pripada hostu koji pokušavate dosegnuti, jer drugim partnerima govori koji se releji smiju koristiti za dosezanje tog hosta. Smjestiti ga na klijent koji započinje vezu ne čini ništa za smjer koji klijent treba:

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

Partneri taj popis prijavljuju zajedno sa svojim adresama kada se prijave lighthouseu, pa se objava širi otkrivanjem, a ne izravnom razmjenom. Ako odredište ne dosegne nijedan lighthouse, njegov se popis releja nikada ne proširi i ispravno konfiguriran relej ostaje besposlen. Taj kvar izgleda točno kao pokvareni relej i nije.

Dajte odredištu početni put u istom prolazu. Statička karta hostova veže Nebula adresu uz javnu krajnju točku kako bi prvo rukovanje imalo kamo otići, i treba joj unos za relej ako odredište treba prihvaćati proslijeđeni promet s hostova koje ne doseže izravno:

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

Dopustite partneru koji se spaja da koristi relej

Strana koja započinje treba vlastito dopuštenje. relay.use_relays je prema zadanim postavkama uključen, pa je slučaj koji vrijedi tražiti izričiti false, često kopiran iz predloška napisanog prije nego što je funkcija releja postojala ili ostavljen od ranijeg pokušaja da se izravni putevi prisile:

relay:
  use_relays: true

Dopuštenje na ovoj strani nije jedina vrata. Dolazna pravila odredišta i dalje se primjenjuju na proslijeđeni paket, a izvor s kojim se uspoređuju jest identitet unutar tunela, a ne adresa samog releja. Kada proslijeđeno rukovanje završi, a aplikacija još uvijek zakaže, pročitajte u zapisniku odredišta koji je izvor zabilježen prije nego prepišete pravilo.

Postavke prolaska kroz NAT djeluju zajedno sa svim ovim. punchy.punch pomaže dvama partnerima otvoriti izravni put, i kada to uspije, nema proslijeđenog prometa za promatranje; to je uspjeh, a ne nedostajući relej. Par koji radi s prekidima obično znači da probijanje uspijeva samo ponekad, zato taj par testirajte nekoliko puta umjesto da iz jednog pokušaja izvučete zaključak.

Provjerite s parom koji je zakazao, a zatim ponovno učitajte

Testirajte ona dva hosta koja su doista zakazala, s aplikacijom koja im treba. Uspješan ping s vaše radne stanice na uslugu samog releja ne dokazuje ništa o prosljeđivanju između dva druga partnera, i to je najčešći lažni pozitiv u cijelom ovom postupku.

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

Ponovno učitajte umjesto ponovnog pokretanja i potvrdite da je pokrenuti proces preuzeo datoteku koju ste uredili. Ponovno pokretanje ruši svaki tunel i čini sljedeći test teže čitljivim, dok SIGHUP zadržava proces i daje mu da ponovno pročita konfiguraciju:

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

systemctl reload radi samo kada lokalni unit definira ExecReload, a unit koji se isporučuje s projektom to ne čini, zato je systemctl kill -s HUP korak koji uspijeva na standardnoj instalaciji. Nakon ponovnog učitavanja pročitajte u zapisniku stazu konfiguracije koju je proces otvorio, kako biste znali da je pročitana nova datoteka, a ne ona koju ste smatrali učitanom.

Postavke releja i probijanje NAT djeluju oboje na put; nijedno ne djeluje na identitet. Ako par i dalje zakaže u rukovanju kada su am_relay, relays i use_relays potvrđeni u pokrenutoj konfiguraciji, provjerite predstavljaju li oba hosta certifikate izdane za imena s kojima su konfigurirani i je li CA isti na obje strane. Držite konfiguraciju certifikata i vatrozida nepromijenjenom dok mijenjate jednu transportnu postavku odjednom, jer promjena certifikata i promjena releja u istom testu ne govore ništa o tome koja je od njih pomaknula rukovanje. Neusklađenost imena ili CA zakaže na istom mjestu kao relej koji nikada nije pronađen, i zato ova protuprovjera pripada istom prolazu.

Zatim potvrdite da je svaka izjava u datoteci kojoj pripada:

• am_relay: true na hostu za prosljeđivanje, i taj host dosegljiv preko UDP-a s obje strane.
• relays: s Nebula adresom tog hosta na odredištu.
• use_relays: true na partneru koji započinje vezu.
• Dolazna pravila na odredištu koja i nakon promjene puta dopuštaju stvarni izvor.