Nebula static_host_map: a cím, amelyet egy világítótorony nem adhat meg

Minden világítótorony tud egy gazdagépnek minden más partnerről beszélni, kivéve arról, ahol maga a világítótorony lakik. Valaminek ismertnek kell lennie, mielőtt az overlay létezik, és a Nebula ezt a valamit egyetlen kis térképbe teszi. A térkép overlay-identitást párosít egy címmel, amely a közönséges hálózaton működik. Minden, amit később megtanulunk, attól függ, hogy ez a párosítás helyes legyen.

Két cím, két feladat

Minden Nebula-gazdagépnek van egy overlay-címe, amely rögzített marad, miközben az eszköz hálózatok között mozog. Ez a cím az identitás, amelyet a tanúsítványok, a tűzfal-szabályok és a partnerkapcsolatok használnak, és önmagában sehová nem irányít. Az elérhető végpont más: egy gazdagépnév vagy cím az alatta lévő hálózaton plusz egy UDP-port, és ez változik, valahányszor a gép helyet változtat. A statikus térkép a kettő közötti kapcsolat.

Csak azok a gazdagépek tartoznak a térképbe, amelyeket hidegen kell tárcsázni, ami általában a világítótornyokat és esetleg egy relét jelent. A lista rövid tartása tervezési cél, mert minden kézi bejegyzés olyan ténnyé válik, amelyet valakinek karban kell tartania. A két címtípus összekeverése a szokásos konfigurációs hiba: a világítótornyok listájára tett nyilvános cím nem indítja el a felderítést.

Az identitás oda megy, ahol identitást várnak. Az elérhetőség a térképbe megy.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Egy térképbejegyzés anatómiája

A kulcs az idézőjelek közé írt overlay-cím, az érték pedig végpontok listája, így egy identitásnak több belépési pontja lehet. Minden végpont hordoz egy gazdagépet és egy portot, és a portnak meg kell egyeznie azzal, amire a másik fél valóban figyel. A Nebula alapértéke az UDP 4242, ami kiindulópont, és nem ígéret a te telepítésedről.

Több végpont akkor hasznos, ha egy világítótoronynak több befelé vezető útja van, például egy nyilvános cím és egy privát cím az ugyanabban a szegmensben lévő gazdagépeknek. A kliens sorrendben próbálja őket, ezért tedd a legmegbízhatóbbat elsőnek. IPv6 esetén tedd a címet szögletes zárójelek közé, mielőtt hozzáfűzöd a portot; az ezzel való hibázás olyan elemzési hibát ad, amely a rossz sorra mutat.

A rossz port csendet ad hiba helyett, mert az UDP-nek nincs kézfogása, amellyel visszautasíthatna. Ezért érdemes a bejegyzés formátumát a Nebula static_host_map referenciájával összevetni, nem az emlékezettel. A referencia a végpontlistákat és a DNS-frissítés viselkedését is lefedi.

A bootstrapnak az overlay előtt kell működnie

A térképben lévő DNS-névnek azon a feloldón keresztül kell feloldódnia, amely a gazdagépen bármilyen alagút előtt van, azaz a szokásos rendszerfeloldón. Teszteld ugyanarról a gépről, indításkor, leállított overlay mellett. Egy név, amely csak az overlay saját DNS-én keresztül oldódik fel, nem tudja bootstrappelni az overlayt. Ugyanez a teszt vonatkozik az útvonalra: az a tűzfalszabály, amely engedi az overlayt, de az első UDP-cserét nem, blokkolja a kezdő csomagot.

Vizsgáld meg a portot UDP-eszközzel ahelyett, hogy feltételeznéd, nyitva van. Erősítsd meg, hogy az útvonalon lévő bármely porttovábbítás a helyes belső gazdagépre mutat, és hogy létezik visszaút. Ha a gazdagépnév több címre oldódik fel, teszteld mindegyiket, mert a kliens választhat olyan címet, amelyet soha nem ellenőriztél.

A statikus bejegyzéseket közvetlenül tárcsázzák, és soha nem kérdeznek világítótornyot. Ezért a hiba itt egyszerű időtúllépésnek látszik partner nélkül.

Mi történik az első kézfogás után

Amint egy gazdagép eléri a világítótornyot, további kézi bejegyzések nélkül megtudja a partnereket és elérhető címeiket. A gazdagépek, amelyek az utolsó kapcsolat óta elmozdultak, ezen a csatornán keresztül felderíthetővé válnak. Ez a jutalom a kézi térkép kicsin tartásáért.

A gazdagépek saját további elérhető címeket is hirdethetnek, és így egy ismert nyilvános cím mögötti partner segít másoknak megtalálni. Ezeket a hirdetéseket megtanulják, nem írják be a statikus térképbe.

A frissítési viselkedés fontos a DNS-névként írt végpontoknál, mert a feloldott cím megváltozhat, miközben a folyamat tovább fut. A Nebula beállításai szabályozzák, hogyan történnek ezek a keresések, beleértve azt is, melyik feloldót használja, ezért olvasd el őket, ne feltételezd a rendszer alapértelmezését. Egy olyan gazdagépen, amelynek feloldója megváltozik, amikor egy alagút feljön, a rossz beállítás működő bootstrapot olyan névvé tehet, amely a munkamenet közepén abbahagyja a feloldást. A keresés stabil feloldóhoz rögzítése gyakran a különbség a megbízható overlay és az akadozó között.

Amikor a felderítés működik, és egy partner nem

Ha a világítótornyok elérhetők, és a legtöbb partner csatlakozik, a bootstrap nem a probléma. A maradék pár vagy nem talál használható utat egymáshoz, vagy az elérhetőség felett hiúsul meg. A világítótorony címének újabb írásmódja egyik esetet sem javítja.

Ellenőrizd a párt, mielőtt szerkesztenéd a térképet, amelyre már minden más támaszkodik. A térkép módosítása minden gazdagépet zavar, ezért ez az utolsó dolog, amihez hozzá kell nyúlni, nem az első.

Kezdd ugyanazon hatóság tanúsítványaival, mert egy elutasított kézfogás messziről elérhetetlen partnernek látszhat. Utána ellenőrizd, hogy a pár tud-e közvetlen utat létesíteni, és hogy van-e relay beállítva a közvetlen forgalmat elutasító hálózatokhoz. A relay egy ugrást és egy függőséget ad hozzá, de támogatott válasz, és a pár útjának javítása más feladat, mint a felderítés javítása.