Nebula advertise_addrs eller static_host_map: vælg efter ejer

Indstillingerne static_host_map og advertise_addrs sætter begge en adresse foran en peer, og de svarer på forskellige spørgsmål. Den ene er en lokal fil, der lister en overlay-adresse og underlay-endepunktet, der skal ringes til. Den anden er en vært, der fortæller sine fyrtårne, hvilke yderligere endepunkter der kan nå den. Ejerskabet er den egentlige forskel: kortet vedligeholdes af alle, der har brug for det, og annoncen af værten selv.

Beslut ud fra, hvem der ejer informationen

Hver skiftende peer i hver peers statiske fil er et vedligeholdelsesarbejde, der vokser med flådens kvadrat. Det er den praktiske grund til at gribe efter den anden indstilling, når værten selv kender svaret.

Ejerskabsspørgsmålet forudsiger også, hvad der sker, når en adresse ændres. Med et statisk kort skal nogen huske hver peer, der har den gamle post. Med en annonce offentliggør værten det nye endepunkt, og dens fyrtårne sender det videre, så ændringen forbliver lokal på maskinen, der flyttede.

Bootstrap kræver stadig statiske poster

En klient skal nå mindst ét fyrtårn, før den kan spørge nogen om andre peers. Det første hop kan ikke komme fra opdagelse, så det kommer fra en statisk post i klientens konfiguration. Få den ene post rigtig, og resten af overlayet kan læres.

En kortpost parrer en Nebula-adresse med et eller flere nåbare IP- eller DNS-endepunkter og porte. At holde fyrtårnene der er normalt; at holde hver peer der er mønsteret, der ældes dårligt, fordi hver ny peer betyder redigering af filer på maskiner, du måske ikke kontrollerer. Hold listen kort nok til, at en person stadig kan verificere den ved at læse den.

Annoncér, når værten kender endepunktet

En vært bag portvideresendelse er nåbar på en offentlig adresse, der ikke er tildelt nogen af dens egne netværksgrænseflader. Den kan ikke opdage den adresse ved at se på sig selv. advertise_addrs lader den offentliggøre endepunktet gennem sine fyrtårne, så andre peers lærer en vej, der faktisk virker. Indstillingen findes netop, fordi værten er den eneste part, der ved, at mappingen blev lavet.

Brug den adresse og port, som andre peers reelt kan nå. Samme ræsonnement gælder for en vært med flere netværksveje, hvor én vej er at foretrække for peers på et bestemt netværk. Annoncering er en udtalelse om underlayet, ikke en anmodning om noget. Når mappingen ændres, opdater annoncen på værten, og lad opdagelsen bære den, i stedet for at redigere statiske filer i hele flåden.

Annoncering er ikke nåbarhed

At offentliggøre et endepunkt opretter ikke routerens videresendelsesregel, åbner ikke en firewall opstrøms og får ikke et DNS-navn til at slå op. Det er separate stykker arbejde, og en korrekt annonce med en manglende portvideresendelse producerer præcis den fejl, du prøvede at rette. Annoncering er en påstand om nåbarhed, ikke en mekanisme, der etablerer den.

Kontroller vejen udefra, før du bebrejder opdagelsen. En peer, der lærer endepunktet, men ikke kan fuldføre et handshake, har et routing- eller filtreringsproblem på underlayet, og at gentage den samme adresse i begge indstillinger ændrer ikke det.

Hold overlay-adressen adskilt fra endepunktet

Nodens certifikat identificerer dens Nebula-adresse. De annoncerede adresser tilhører det underliggende netværk og må ændres uden at røre certifikatet. At udstede et nyt certifikat med en anden overlay-IP er en anden operation med sine egne konsekvenser for hvert tillidsforhold, der fastgjorde den gamle. Hold de to ændringer adskilt i runbooken, ellers vil en endepunktsflytning blive registreret som en genudstedelse.

Når triage går i stå, skal du eksplicit adskille de to lag: returnerer opdagelsen det forventede endepunkt, og når et handshake det? Hvis opdagelsen er rigtig, og pakkerne fejler, er problemet under overlayet. Hvis opdagelsen er forkert, er problemet i kortet eller annoncen, og rettelsen hører der.