Nebula static_host_map: adressen et fyrtårn ikke kan gi

Hvert fyrtårn kan fortelle en vert om hver annen peer bortsett fra hvor fyrtårnet selv bor. Noe må være kjent før overlayet finnes, og Nebula legger det noe i ett lite kart. Kartet parrer en overlay-identitet med en adresse som virker på det vanlige nettet. Alt som læres senere, avhenger av at det paret er riktig.

To adresser med to oppgaver

Hver Nebula-vert eier en overlay-adresse som står fast mens enheten flytter seg mellom nett. Den adressen er identiteten som sertifikater, brannmurregler og peer-forhold bruker, og alene ruter den ingen steder. Endepunktet som nås er noe annet: et vertsnavn eller en adresse på det underliggende nettet pluss en UDP-port, og det endres hver gang maskinen skifter plass. Det statiske kartet er forbindelsen mellom de to.

Bare verter som må ringes opp kaldt hører i kartet, noe som vanligvis betyr fyrtårnene og kanskje en relay. Å holde listen kort er et designmål, fordi hver manuelle oppføring blir et faktum noen må vedlikeholde. Å forveksle de to adressetypene er den vanlige konfigurasjonsfeilen: en offentlig adresse plassert i fyrtårnlisten får ikke oppdagelsen til å starte.

Identitet går dit identitet forventes. Nåbarhet 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 en kartoppføring

Nøkkelen er overlay-adressen skrevet som en streng i anførselstegn, og verdien er en liste med endepunkter, så én identitet kan ha flere innganger. Hvert endepunkt bærer en vert og en port, og porten må samsvare med det den andre siden faktisk lytter på. Nebulas standard er UDP 4242, som er et utgangspunkt og ikke et løfte om utrullingen din.

Flere endepunkter er nyttige når et fyrtårn har mer enn én vei inn, slik som en offentlig adresse og en privat adresse for verter i samme segment. Klienten prøver dem i rekkefølge, så sett den mest pålitelige først. For IPv6 setter du adressen i hakeparenteser før porten legges til; å gjøre det feil gir en parsefeil som peker på feil linje.

En feil port gir stillhet i stedet for en feil, fordi UDP ikke har noe håndtrykk å avvise med. Derfor er det verdt å sjekke formatet på oppføringen mot Nebulas referanse for static_host_map i stedet for hukommelsen. Referansen dekker også endepunktlister og DNS-oppdateringsatferd.

Bootstrap må virke før overlayet

Et DNS-navn i kartet må løses gjennom den resolveren verten har før noen tunnel finnes, det vil si den vanlige systemresolveren. Test det fra samme maskin ved oppstart med overlayet stoppet. Et navn som bare løses gjennom overlayets egen DNS, kan ikke bootstrappe overlayet. Den samme testen gjelder for ruten: en brannmurregel som tillater overlayet men ikke den første UDP-utvekslingen, blokkerer den første pakken.

Sjekk porten med et UDP-verktøy i stedet for å anta at den er åpen. Bekreft at enhver portvideresending på veien peker på riktig intern vert og at det finnes en returvei. Hvis vertsnavnet løses til flere adresser, test hver enkelt, fordi en klient kan velge en adresse du aldri har sjekket.

Statiske oppføringer ringes direkte og spør aldri et fyrtårn. Derfor ser en feil her ut som en vanlig tidsavbrudd uten noen involvert peer.

Hva som skjer etter det første håndtrykket

Når en vert først når et fyrtårn, lærer den om peers og deres nåbare adresser uten flere manuelle oppføringer. Verter som har flyttet seg siden forrige tilkobling, blir oppdagbare gjennom den kanalen. Det er gevinsten ved å holde det manuelle kartet lite.

Verter kan også annonsere egne ekstra nåbare adresser, og slik hjelper en peer bak en kjent offentlig adresse andre med å finne den. Disse annonsene læres, de skrives ikke i det statiske kartet.

Oppdateringsatferd betyr noe for endepunkter skrevet som DNS-navn, fordi en løst adresse kan endre seg mens prosessen fortsetter å kjøre. Nebulas innstillinger styrer hvordan disse oppslagene skjer, inkludert hvilken resolver som brukes, så les dem i stedet for å anta systemstanden. På en vert der resolveren endres når en tunnel kommer opp, kan feil innstilling gjøre et fungerende bootstrap til et navn som slutter å løses midt i økten. Å feste oppslaget til en stabil resolver er ofte forskjellen mellom et pålitelig overlay og et ustabilt.

Når oppdagelsen virker og én peer ikke

Hvis fyrtårnene nås og de fleste peers kobler til, er ikke bootstrapet problemet. Det gjenværende paret finner enten ingen brukbar vei til hverandre eller feiler over nåbarheten. Å legge til en annen stavemåte for fyrtårnets adresse reparerer ingen av de to tilfellene.

Sjekk paret før du redigerer kartet som alt annet allerede hviler på. En kartendring forstyrrer hver vert, så det er det siste man rører, ikke det første.

Begynn med sertifikater fra samme myndighet, fordi et avvist håndtrykk på avstand kan se ut som en uoppnåelig peer. Sjekk deretter om paret kan etablere en direkte vei og om en relay er konfigurert for nett som avviser direkte trafikk. En relay legger til et hopp og en avhengighet, men det er et støttet svar, og å reparere peerens vei er en annen oppgave enn å reparere oppdagelsen.