Nebula static_host_map: den adresse, et fyrtårn ikke kan give

Hvert fyrtårn kan fortælle en vært om hver anden peer undtagen hvor fyrtårnet selv bor. Noget skal være kendt, før overlayet findes, og Nebula lægger det noget i et lille kort. Kortet parrer en overlay-identitet med en adresse, der virker på det almindelige netværk. Alt, hvad der læres senere, afhænger af, at parret er rigtigt.

To adresser med to opgaver

Hver Nebula-vært ejer en overlay-adresse, der står fast, mens enheden flytter sig mellem netværk. Den adresse er identiteten, som certifikater, firewallregler og peer-forhold bruger, og alene router den ingen steder hen. Det nåbare endpoint er noget andet: et værtsnavn eller en adresse på det underliggende netværk plus en UDP-port, og det ændrer sig, hver gang maskinen skifter placering. Det statiske kort er forbindelsen mellem de to.

Kun værter, der skal ringes op koldt, hører i kortet, hvilket normalt betyder fyrtårnene og måske en relay. At holde listen kort er et designmål, fordi hver manuel post bliver en kendsgerning, som nogen skal vedligeholde. At forveksle de to adressetyper er den sædvanlige konfigurationsfejl: en offentlig adresse placeret i fyrtårnslisten får ikke opdagelsen til at starte.

Identitet går derhen, hvor identitet forventes. Nåbarhed går i kortet.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomien af en kortpost

Nøglen er overlay-adressen skrevet som en streng i citationstegn, og værdien er en liste af endpoints, så én identitet kan have flere indgange. Hvert endpoint bærer en vært og en port, og porten skal svare til det, den anden side faktisk lytter på. Nebulas standard er UDP 4242, hvilket er et udgangspunkt og ikke et løfte om din udrulning.

Flere endpoints er nyttige, når et fyrtårn har mere end én vej ind, såsom en offentlig adresse og en privat adresse til værter på samme segment. Klienten prøver dem i rækkefølge, så sæt den mest pålidelige først. For IPv6 skal adressen i klammer, før porten tilføjes; gør man det forkert, giver det en parsefejl, der peger på den forkerte linje.

En forkert port giver tavshed i stedet for en fejl, fordi UDP ikke har noget håndtryk at afvise med. Derfor er det værd at tjekke postens format mod Nebulas reference for static_host_map i stedet for hukommelsen. Referencen dækker også endpointlister og DNS-opdateringsadfærd.

Bootstrap skal virke før overlayet

Et DNS-navn i kortet skal opløses gennem den resolver, værten har, før nogen tunnel findes, altså den almindelige systemresolver. Test det fra samme maskine ved opstart med overlayet stoppet. Et navn, der kun opløses gennem overlayets egen DNS, kan ikke bootstrappe overlayet. Samme test gælder for ruten: en firewallregel, der tillader overlayet men ikke den første UDP-udveksling, blokerer den indledende pakke.

Undersøg porten med et UDP-værktøj i stedet for at antage, at den er åben. Bekræft, at enhver portvideresendelse på vejen peger på den rigtige interne vært, og at der findes en returvej. Hvis værtsnavnet opløses til flere adresser, så test hver enkelt, fordi en klient kan vælge en adresse, du aldrig har tjekket.

Statiske poster ringes direkte op og spørger aldrig et fyrtårn. Derfor ser en fejl her ud som en almindelig timeout uden nogen involveret peer.

Hvad sker der efter det første håndtryk

Når en vært først når et fyrtårn, lærer den om peers og deres nåbare adresser uden flere manuelle poster. Værter, der er flyttet siden sidste forbindelse, bliver opdagelige gennem den kanal. Det er gevinsten ved at holde det manuelle kort lille.

Værter kan også annoncere egne yderligere nåbare adresser, og det er sådan en peer bag en kendt offentlig adresse hjælper andre med at finde den. De annoncer læres, de skrives ikke i det statiske kort.

Opdateringsadfærd betyder noget for endpoints skrevet som DNS-navne, fordi en opløst adresse kan ændre sig, mens processen kører videre. Nebulas indstillinger styrer, hvordan disse opslag sker, herunder hvilken resolver der bruges, så læs dem i stedet for at antage systemstandarden. På en vært, hvis resolver ændres, når en tunnel kommer op, kan den forkerte indstilling gøre et fungerende bootstrap til et navn, der holder op med at opløses midt i sessionen. At fastgøre opslaget til en stabil resolver er ofte forskellen mellem et pålideligt overlay og et ustabilt.

Når opdagelse virker, og én peer ikke gør

Hvis fyrtårnene kan nås, og de fleste peers forbinder, er bootstrap ikke problemet. Det resterende par kan enten ikke finde en brugbar vej til hinanden eller fejler over nåbarhed. At tilføje endnu en stavemåde af fyrtårnets adresse kan ikke reparere nogen af de to tilfælde.

Tjek parret, før du redigerer det kort, som alt andet allerede hviler på. En kortændring forstyrrer hver vært, så det er det sidste, man rører ved, ikke det første.

Start med certifikater fra samme myndighed, fordi et afvist håndtryk på afstand kan ligne en uopnåelig peer. Tjek derefter, om parret kan etablere en direkte vej, og om der er konfigureret en relay til netværk, der afviser direkte trafik. En relay tilføjer et hop og en afhængighed, men det er et understøttet svar, og at rette peerens vej er en anden opgave end at rette opdagelsen.