Nebula static_host_map: adresa koju svjetionik ne može dati

Svaki svjetionik može hostu reći o svakom drugom peeru osim o mjestu na kojem sam svjetionik živi. Nešto mora biti poznato prije nego overlay postoji, a Nebula to nešto stavlja u jednu malu kartu. Karta povezuje overlay identitet s adresom koja radi na običnoj mreži. Sve što se kasnije nauči zavisi od toga da to povezivanje bude ispravno.

Dvije adrese s dva zadatka

Svaki Nebula host ima overlay adresu koja ostaje fiksna dok se uređaj kreće između mreža. Ta adresa je identitet koji koriste certifikati, pravila vatrozida i peer odnosi, a sama po sebi ne usmjerava nikamo. Dostupna krajnja točka je nešto drugo: ime hosta ili adresa na podložnoj mreži plus UDP port, i mijenja se kad god stroj promijeni lokaciju. Statička karta je spoj između njih.

U kartu ulaze samo hostovi koji se moraju birati hladni, što obično znači svjetionici i možda jedan relay. Držati taj popis kratkim je dizajnerski cilj, jer svaki ručni unos postaje činjenica koju netko mora održavati. Brkanje dvaju tipova adresa uobičajena je pogreška u konfiguraciji: javna adresa stavljena na popis svjetionika ne pokreće otkrivanje.

Identitet ide tamo gdje se identitet očekuje. Dostupnost ide u kartu.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomija unosa u kartu

Ključ je overlay adresa zapisana kao niz u navodnicima, a vrijednost je popis krajnjih točaka, pa jedan identitet može imati više ulaznih točaka. Svaka krajnja točka nosi host i port, a port mora odgovarati onome što druga strana zaista sluša. Nebula zadano je UDP 4242, što je početna točka, a ne obećanje o vašem postavljanju.

Više krajnjih točaka korisno je kad svjetionik ima više od jednog puta unutra, poput javne adrese i privatne adrese za hostove na istom segmentu. Klijent ih pokušava redom, pa najpouzdaniji stavite prvi. Za IPv6 stavite adresu u uglate zagrade prije dodavanja porta; pogreška u tome daje pogrešku parsiranja koja pokazuje na pogrešan redak.

Pogrešan port daje tišinu umjesto pogreške, jer UDP nema handshake koji bi odbio. Zato format unosa vrijedi provjeriti prema Nebula referenci za static_host_map a ne po sjećanju. Referenca pokriva i popise krajnjih točaka te ponašanje osvježavanja DNS-a.

Bootstrap mora raditi prije overlaya

DNS ime u karti mora se razriješiti kroz resolver koji host ima prije nego postoji bilo koji tunel, a to je obični sistemski resolver. Testirajte to s istog stroja, pri podizanju, sa zaustavljenim overlayem. Ime koje se razrješava samo kroz vlastiti DNS overlaya ne može bootstrappati overlay. Isti test vrijedi za rutu: pravilo vatrozida koje dopušta overlay ali ne i prvu UDP razmjenu blokira početni paket.

Provjerite port UDP alatom umjesto da pretpostavite da je otvoren. Potvrdite da svako prosljeđivanje porta na putu cilja na ispravan interni host i da povratni put postoji. Ako se ime hosta razrješava na više adresa, testirajte svaku, jer klijent može odabrati adresu koju nikad niste provjerili.

Statički unosi biraju se izravno i nikad ne pitaju svjetionik. Zato kvar ovdje izgleda kao običan timeout bez uključenog peera.

Što se događa nakon prvog handshakea

Kad host dosegne svjetionik, sazna za peere i njihove dostupne adrese bez dodatnih ručnih unosa. Hostovi koji su se pomaknuli od posljednje veze postaju otkrivljivi kroz taj kanal. To je nagrada za držanje ručne karte malom.

Hostovi mogu i oglašavati vlastite dodatne dostupne adrese, i tako peer iza poznate javne adrese pomaže drugima da ga pronađu. Ta se oglašavanja uče, ne upisuju u statičku kartu.

Ponašanje osvježavanja važno je za krajnje točke zapisane kao DNS imena, jer se razriješena adresa može promijeniti dok proces nastavlja raditi. Nebula postavke kontroliraju kako se ta pretraživanja odvijaju, uključujući koji se resolver koristi, pa ih čitajte umjesto da pretpostavite sistemski default. Na hostu čiji se resolver mijenja kad tunel ustane, pogrešna postavka može pretvoriti radni bootstrap u ime koje prestaje da se razrješava usred sesije. Pričvršćivanje pretraživanja na stabilan resolver često je razlika između pouzdanog overlaya i onog s prekidima.

Kad otkrivanje radi a jedan peer ne

Ako su svjetionici dostupni i većina peerova se povezuje, bootstrap nije problem. Preostali par ili ne može naći upotrebljiv put jedno do drugog ili pada iznad dostupnosti. Dodavanje još jednog zapisa adrese svjetionika ne može popraviti nijedan od ta dva slučaja.

Provjerite par prije nego uredite kartu na koju se sve ostalo već oslanja. Promjena karte uznemiruje svaki host, pa je to posljednje što treba dirati, a ne prvo.

Počnite s certifikatima istog autoriteta, jer odbijen handshake može izdaleka izgledati kao nedostupan peer. Zatim provjerite može li par uspostaviti izravan put i je li relay konfiguriran za mreže koje odbijaju izravni promet. Relay dodaje hop i ovisnost, ali je podržan odgovor, a popravljanje puta peera drugi je zadatak od popravljanja otkrivanja.