Nebula advertise_addrs vagy static_host_map: válassz a tulajdonos szerint
A statikus térképet minden peer karbantartja, amely rácsatlakozik; a hirdetett címet a gazdagép teszi közzé. A szerint válassz, ki ismeri a végpontot.
A static_host_map és a advertise_addrs beállítás is címeket tesz egy peer elé, és különböző kérdésekre válaszolnak. Az egyik egy helyi fájl, amely felsorol egy overlay-címet és a tárcsázandó underlay-végpontot. A másik egy gazdagép, amely elmondja a jelzőfényeinek, mely további végpontok érhetik el. A valódi különbség a tulajdon: a térképet mindenki karbantartja, akinek szüksége van rá, a hirdetményt pedig maga a gazdagép.
Dönts aszerint, ki birtokolja az információt
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Minden változó peer minden peer statikus fájljában olyan karbantartási munka, amely a flotta négyzetével nő. Ez a gyakorlati ok arra, hogy a másik beállításhoz nyúljunk, valahányszor maga a gazdagép tudja a választ.
A tulajdon kérdése azt is előrejelzi, mi történik, amikor egy cím megváltozik. Statikus térképnél valakinek emlékeznie kell minden peerre, akinél a régi bejegyzés van. Hirdetmény esetén a gazdagép közzéteszi az új végpontot, és a jelzőfényei továbbadják, így a változás helyi marad azon a gépen, amely elköltözött.
A bootstrapnek még mindig statikus bejegyzések kellenek
Az ügyfélnek el kell érnie legalább egy jelzőfényt, mielőtt bárkitől más peerek felől kérdezhetne. Ez az első ugrás nem jöhet felderítésből, ezért egy statikus bejegyzés az ügyfél konfigurációjában szükséges. Tedd helyessé azt az egy bejegyzést, és az overlay többi része megtanulható.
A térképbejegyzés egy Nebula-címet párosít egy vagy több elérhető IP- vagy DNS-végponttal és porttal. A jelzőfényeket ott tartani normális; minden peert ott tartani az a minta, amely rosszul öregszik, mert minden új peer fájlok szerkesztését jelenti olyan gépeken, amelyeket talán nem te irányítasz. Tartsd a listát elég rövidnek, hogy egy ember még ellenőrizhesse olvasással.
Hirdesd, amikor a gazdagép ismeri a végpontot
A porttovábbítás mögötti gazdagép egy nyilvános címen érhető el, amely nincs hozzárendelve egyik saját interfészéhez sem. Nem tudja felfedezni ezt a címet önmagára nézve. A advertise_addrs lehetővé teszi számára, hogy a jelzőfényein keresztül közzétegye a végpontot, hogy más peerek olyan útvonalat tanuljanak, amely valóban működik. A beállítás éppen azért létezik, mert a gazdagép az egyetlen fél, aki tudja, hogy a leképezés megtörtént.
Azt a címet és portot használd, amelyet más peerek valóban elérhetnek. Ugyanez az érvelés érvényes egy több hálózati útvonallal rendelkező gazdagépre, ahol az egyik útvonal előnyösebb egy adott hálózaton lévő peerek számára. A hirdetés állítás az underlayről, nem kérés bármire. Amikor a leképezés megváltozik, frissítsd a hirdetményt a gazdagépen, és hagyd, hogy a felderítés vigye tovább, ahelyett hogy statikus fájlokat szerkesztenél a teljes flottán.
A hirdetés nem elérhetőség
Egy végpont közzététele nem hozza létre az útválasztó továbbítási szabályát, nem nyit meg egy felsőbb tűzfalat, és nem éri el, hogy egy DNS-név feloldódjon. Ezek külön munkadarabok, és egy helyes hirdetmény hiányzó porttovábbítással pontosan azt a hibát állítja elő, amelyet javítani próbáltál. A hirdetés állítás az elérhetőségről, nem mechanizmus, amely létrehozná.
Ellenőrizd az útvonalat kívülről, mielőtt a felderítést okolnád. Annak a peernek, amely megtanulja a végpontot, de nem tud befejezni egy handshake-et, útvonalválasztási vagy szűrési problémája van az underlayen, és ugyanazon cím megismétlése mindkét beállításban nem változtat ezen.
Tartsd az overlay-címet külön a végponttól
A csomópont tanúsítványa azonosítja a Nebula-címét. A hirdetett címek a mögöttes hálózathoz tartoznak, és megváltozhatnak anélkül, hogy hozzányúlnánk a tanúsítványhoz. A Új tanúsítvány kibocsátása más overlay-IP-vel más művelet, saját következményekkel minden bizalmi kapcsolatra, amely a régit rögzítette. Tartsd a két változtatást külön a runbookban, különben a végpont áthelyezése újrakibocsátásként kerül rögzítésre.
Amikor a triage elakad, válaszd szét a két réteget egyértelműen: visszaadja-e a felderítés a várt végpontot, és eléri-e egy handshake? Ha a felderítés helyes és a csomagok elbuknak, a probléma az overlay alatt van. Ha a felderítés hibás, a probléma a térképben vagy a hirdetményben van, és a javítás oda tartozik.