Nebula static_host_map: adressa eit fyrtårn ikkje kan gje

Kvart fyrtårn kan fortelje ein vert om kvar annan peer bortsett frå kvar fyrtårnet sjølv bur. Noko må vere kjent før overlayet finst, og Nebula legg det noko i eitt lite kart. Kartet parar ein overlay-identitet med ei adresse som verkar på det vanlege nettet. Alt som blir lært seinare, er avhengig av at det paret er riktig.

To adresser med to oppgåver

Kvar Nebula-vert eig ei overlay-adresse som står fast medan eininga flyttar seg mellom nett. Den adressa er identiteten som sertifikat, brannmurreglar og peer-tilhøve brukar, og åleine ruter ho ingen stad. Endepunktet ein når er noko anna: eit vertsnamn eller ei adresse på det underliggande nettet pluss ein UDP-port, og det endrar seg kvar gong maskinen skiftar plass. Det statiske kartet er sambandet mellom dei to.

Berre vertar som må ringjast opp kaldt høyrer i kartet, noko som vanlegvis tyder fyrtårna og kanskje ein relay. Å halde lista kort er eit designmål, fordi kvar manuelle oppføring blir eit faktum nokon må vedlikehalde. Å forveksle dei to adressetypane er den vanlege konfigurasjonsfeilen: ei offentleg adresse plassert i fyrtårnlista får ikkje oppdaginga til å starte.

Identitet går dit identitet blir venta. Nåbarheit går i kartet.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomi av ei kartoppføring

Nøkkelen er overlay-adressa skriven som ein streng i hermeteikn, og verdien er ei liste med endepunkt, så éin identitet kan ha fleire inngangar. Kvart endepunkt ber ein vert og ein port, og porten må svare til det den andre sida faktisk lyttar på. Standardverdien i Nebula er UDP 4242, som er eit utgangspunkt og ikkje eit løfte om utrullinga di.

Fleire endepunkt er nyttige når eit fyrtårn har meir enn éin veg inn, slik som ei offentleg adresse og ei privat adresse for vertar i same segment. Klienten prøver dei i rekkjefølgje, så set den mest pålitelege først. For IPv6 set du adressa i hakeparentesar før porten blir lagd til; å gjere det feil gir ein parsefeil som peikar på feil linje.

Ein feil port gir stille i staden for ein feil, fordi UDP ikkje har noko handtrykk å avvise med. Derfor er det verdt å sjekke formatet på oppføringa mot Nebula-referansen for static_host_map i staden for minnet. Referansen dekkjer også endepunktlister og DNS-oppdateringsåtferd.

Bootstrap må verke før overlayet

Eit DNS-namn i kartet må løysast gjennom den resolveren verten har før nokon tunnel finst, det vil seie den vanlege systemresolveren. Test det frå same maskin ved oppstart med overlayet stoppa. Eit namn som berre blir løyst gjennom den eigne DNS-en til overlayet, kan ikkje bootstrappe overlayet. Den same testen gjeld for ruta: ein brannmurregel som tillèt overlayet men ikkje den første UDP-utvekslinga, blokkerer den første pakken.

Sjekk porten med eit UDP-verktøy i staden for å anta at han er open. Stadfest at kvar portvideresending på vegen peikar på rett intern vert og at det finst ein returveg. Viss vertsnamnet blir løyst til fleire adresser, test kvar einskild, fordi ein klient kan velje ei adresse du aldri har sjekka.

Statiske oppføringar blir ringde direkte og spør aldri eit fyrtårn. Derfor ser ein feil her ut som eit vanleg tidsavbrot utan nokon involvert peer.

Kva som skjer etter det første handtrykket

Når ein vert først når eit fyrtårn, lærer han om peers og dei nåbare adressene deira utan fleire manuelle oppføringar. Vertar som har flytta seg sidan førre tilkopling, blir oppdagbare gjennom den kanalen. Det er vinsten ved å halde det manuelle kartet lite.

Vertar kan også annonsere eigne ekstra nåbare adresser, og slik hjelper ein peer bak ei kjend offentleg adresse andre med å finne han. Desse annonsane blir lærte, dei blir ikkje skrivne i det statiske kartet.

Oppdateringsåtferd betyr noko for endepunkt skrivne som DNS-namn, fordi ei løyst adresse kan endre seg medan prosessen held fram med å køyre. Innstillingane i Nebula styrer korleis desse oppslaga skjer, inkludert kva resolver som blir brukt, så les dei i staden for å anta systemstanden. På ein vert der resolveren endrar seg når ein tunnel kjem opp, kan feil innstilling gjere eit fungerande bootstrap til eit namn som sluttar å løysast midt i økta. Å feste oppslaget til ein stabil resolver er ofte skillnaden mellom eit påliteleg overlay og eit ustabilt.

Når oppdaginga verkar og éin peer ikkje

Viss fyrtårna blir nådde og dei fleste peers koplar til, er ikkje bootstrapet problemet. Det attverande paret finn anten ingen brukbar veg til kvarandre eller feilar over nåbarheita. Å leggje til ein annan stavemåte for fyrtårnsadressa reparerer ingen av dei to tilfella.

Sjekk paret før du redigerer kartet som alt anna allereie kviler på. Ei kartendring forstyrrar kvar vert, så det er det siste ein rører, ikkje det første.

Byrj med sertifikat frå same styresmakt, fordi eit avvist handtrykk på avstand kan sjå ut som ein uoppnåeleg peer. Sjekk deretter om paret kan etablere ein direkte veg og om ein relay er konfigurert for nett som avviser direkte trafikk. Ein relay legg til eit hopp og ein avhengigheit, men det er eit støtta svar, og å reparere vegen til peeren er ei anna oppgåve enn å reparere oppdaginga.