Nebula advertise_addrs eller static_host_map: välj efter ägare

Inställningarna static_host_map och advertise_addrs sätter båda en adress framför en peer, och de svarar på olika frågor. Den ena är en lokal fil som listar en overlay-adress och underlay-slutpunkten att ringa. Den andra är en värd som berättar för sina fyrar vilka ytterligare slutpunkter som kan nå den. Ägarskapet är den verkliga skillnaden: kartan underhålls av alla som behöver den, och annonsen av värden själv.

Bestäm efter vem som äger informationen

Varje föränderlig peer i varje peers statiska fil är ett underhållsarbete som växer med flottans kvadrat. Det är det praktiska skälet att ta till den andra inställningen när värden själv kan svaret.

Ägarfrågan förutser också vad som händer när en adress ändras. Med en statisk karta måste någon komma ihåg varje peer som har den gamla posten. Med en annons publicerar värden den nya slutpunkten och dess fyrar skickar den vidare, så ändringen stannar lokalt på maskinen som flyttade.

Bootstrap behöver fortfarande statiska poster

En klient måste nå minst en fyr innan den kan fråga någon om andra peers. Det första hoppet kan inte komma från upptäckt, så det kommer från en statisk post i klientens konfiguration. Gör den enda posten rätt och resten av overlayen kan läras.

En kartpost parar en Nebula-adress med en eller flera nåbara IP- eller DNS-slutpunkter och portar. Att hålla fyrarna där är normalt; att hålla varje peer där är mönstret som åldras dåligt, eftersom varje ny peer innebär att redigera filer på maskiner du kanske inte kontrollerar. Håll listan kort nog att en person fortfarande kan verifiera den genom att läsa den.

Annonsera när värden känner till slutpunkten

En värd bakom portvidarebefordran är nåbar på en offentlig adress som inte är tilldelad något av dess egna gränssnitt. Den kan inte upptäcka den adressen genom att titta på sig själv. advertise_addrs låter den publicera slutpunkten via sina fyrar så att andra peers lär sig en väg som faktiskt fungerar. Inställningen finns just för att värden är den enda parten som vet att mappningen gjordes.

Använd den adress och port som andra peers verkligen kan nå. Samma resonemang gäller en värd med flera nätverksvägar, där en väg är att föredra för peers på ett visst nätverk. Annonsering är ett påstående om underlayet, inte en begäran om något. När mappningen ändras, uppdatera annonsen på värden och låt upptäckten bära den, i stället för att redigera statiska filer i hela flottan.

Annonsering är inte nåbarhet

Att publicera en slutpunkt skapar inte routerns vidarebefordringsregel, öppnar inte en brandvägg uppströms och får inte ett DNS-namn att lösas upp. Det är separata arbetsstycken, och en korrekt annons med en saknad portvidarebefordran ger exakt det fel du försökte åtgärda. Annonsering är ett påstående om nåbarhet, inte en mekanism som etablerar den.

Kontrollera vägen utifrån innan du skyller på upptäckten. En peer som lär sig slutpunkten men inte kan slutföra ett handshake har ett routing- eller filtreringsproblem på underlayet, och att upprepa samma adress i båda inställningarna ändrar inte det.

Håll overlay-adressen åtskild från slutpunkten

Nodens certifikat identifierar dess Nebula-adress. De annonserade adresserna tillhör det underliggande nätverket och får ändras utan att röra certifikatet. Utfärda ett nytt certifikat med en annan overlay-IP är en annan operation, med sina egna konsekvenser för varje förtroendeförhållande som fäste den gamla. Håll de två ändringarna åtskilda i runbooken, annars registreras en slutpunktsflytt som en återutgivning.

När triagen fastnar, skilj de två lagren explicit: returnerar upptäckten den förväntade slutpunkten, och når ett handshake den? Om upptäckten är rätt och paketen misslyckas ligger problemet under overlayen. Om upptäckten är fel ligger problemet i kartan eller annonsen, och rättelsen hör dit.