Nebula-relay beállítva, de használaton kívül: három beállítás, amit ellenőrizni kell

Hozzáadtál egy relay-gazdagépet, beírtad a Nebula-címét egy konfigurációba, és a két partner mégsem beszél egymással. Ez azért történik, mert egy relay-útvonalhoz három külön nyilatkozat kell, amelyeknek egyezniük kell, és ezek közül csak egy van azon a gépen, amelyet valószínűleg szerkesztettél. Ezt kétszer követtem végig: egyszer a továbbító gazdagép soha nem kapta meg a relay-szerepet, egyszer pedig a beállítások a kapcsolat rossz oldalára kerültek. Az alábbi sorrend a szerepet, a hirdetést és az engedélyt ebben a sorrendben ellenőrzi, és minden lépéshez tartozik egy parancs, amely megmondja, folytasd-e.

Térképezd fel a három szerepet, mielőtt egy konfigurációt szerkesztesz

A Nebula minden gazdagépnek ad egy feladatot, és a feladatok nem öröklődnek. A lighthouse válaszol az olyan kérdésekre, mint hogy hol van ez a partner, hogy a gazdagépek megtalálhassák egymást. A relay forgalmat továbbít két partner között, amelyeknek nincs működő közvetlen útvonaluk. Egy közönséges gazdagép egyiket sem teszi. A három fontos beállítás három különböző gépen van, ezért egy teljesnek tűnő klienskonfiguráció mindkét partnert várakozásban tarthatja.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Egyetlen tünet választja el a két hibatípust. Ha mindkét partner listázza a másikat, és a napló olyan kézfogási kísérleteket mutat, amelyek soha nem fejeződnek be, a felderítés működik, és az adatútvonalat NAT vagy tűzfal blokkolja. Ha egy partner egyáltalán nem szerez tudomást a másik címéről, a probléma a lighthouse-ban vagy annak statikus gazdagéptérképében van, és a relay-beállítások ezt nem tudják megjavítani.

Erősítsd meg, melyik konfigurációt töltötte be valójában minden gazdagép, mielőtt bármi mást módosítasz. Az a unit, amely más útvonalat olvas, mint a szerkesztett fájl, gyakori és kínos oka annak, hogy „a módosítás nem csinált semmit”:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

A verziósor vegyes flottában számít. A relay kezelése, a punch viselkedése és az elfogadott konfigurációs kulcsok nem azonosak a kiadások között, ezért ne feltételezd, hogy egy régebbi build ért egy olyan szakaszt, amelyhez nem írták. Állítsd a gazdagépeket azonos minor-sorozatra, majd futtasd a nebula -test -config /etc/nebula/config.yml parancsot minden gazdagépen, és hasonlítsd össze a kimenetet, mielőtt olyan átvitelt hibakeresnél, amelyet a kód nem valósít meg.

Kapcsold be a továbbító szerepet a relay-gazdagépen

A relay-szerep egyetlen jelző a továbbító gazdagépen, és független attól, hogy lighthouse-e. Az a gazdagép, amelyen a felderítés be van kapcsolva és a relay-továbbítás ki van kapcsolva, továbbra is csak felderítő szolgáltatás. A relayen:

relay:
  am_relay: true

Ez a jelző szándékot nyilatkozik ki; nem teremt elérhetőséget. A relaynek mindkét partner felől elérhetőnek kell lennie, ami a gyakorlatban nyilvános címet jelent, bejövő UDP-t a Nebula-porton, nyitva a gazdagép tűzfalában és bármely felhő biztonsági csoportjában, és semmilyen kettős NAT-ot előtte. Ellenőrizd a figyelő socketet, majd figyeld, érkeznek-e a partner csomagjai:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Két korlát később időt takarít meg. Egy relayhez nem lehet egy másik relayen keresztül eljutni, ezért a konfigurációban szereplő relay-nevek lánca nem helyettesíti a továbbító gazdagép használható útvonalát. És a relay csomagokat továbbít; nem ad engedélyt, a cél saját bejövő szabályai döntik el továbbra is, hogy a továbbított folyamat engedélyezett-e. A szerep és követelményei a relay-konfiguráció dokumentációjában vannak.

A relayt a cél felől hirdesd, ne a kliens felől

Ez az a megfordítás, amely a legtöbb órát felemészti. A relay-lista ahhoz a gazdagéphez tartozik, amelyet el akarsz érni, mert megmondja a többi partnernek, mely relayek használhatók annak a gazdagépnek az eléréséhez. Ha arra a kliensre teszed, amely a kapcsolatot indítja, az semmit sem tesz a kliens által igényelt irányért:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

A partnerek ezt a listát a címeikkel együtt jelentik, amikor bejelentkeznek a lighthouse-nál, így a hirdetés a felderítésen keresztül terjed, nem közvetlen cserével. Ha a cél nem ér el egyetlen lighthouse-ot sem, a relay-listája soha nem terjed el, és egy helyesen beállított relay tétlen marad. Ez a hiba pontosan úgy néz ki, mint egy tönkrement relay, és nem az.

Adj a célnak indító útvonalat ugyanabban a menetben. A statikus gazdagéptérkép egy Nebula-címet nyilvános végponthoz köt, hogy az első kézfogásnak legyen hová mennie, és szüksége van egy bejegyzésre a relayhez, ha a célnak el kell fogadnia továbbított forgalmat olyan gazdagépektől, amelyeket nem ér el közvetlenül:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Engedd, hogy a csatlakozó partner használja a relayt

A kezdeményező oldalnak saját engedélyre van szüksége. A relay.use_relays alapértelmezés szerint be van kapcsolva, tehát a keresésre érdemes eset egy kifejezett false, amelyet gyakran a relay-funkció előtt írt sablonból másoltak, vagy egy korábbi, közvetlen útvonalakat erőltetni próbáló kísérlet hagyott hátra:

relay:
  use_relays: true

Az ezen az oldalon adott engedély nem az egyetlen kapu. A cél bejövő szabályai továbbra is érvényesek a továbbított csomagra, és az a forrás, amelyhez illesztik őket, a tunelen belüli identitás, nem magának a relaynek a címe. Amikor a továbbított kézfogás befejeződik és az alkalmazás továbbra is hibázik, olvasd el a cél naplójában a rögzített forrást, mielőtt bármely szabályt átírnál.

A NAT-átjárási beállítások mindezzel együtt hatnak. A punchy.punch segít két partnernek közvetlen útvonalat nyitni, és amikor sikerül, nincs megfigyelhető relay-forgalom; ez siker, nem hiányzó relay. Egy időszakosan működő pár általában azt jelenti, hogy a punch csak néha sikerül, ezért többször teszteld azt a párt, ahelyett hogy egyetlen kísérletből vonnál le következtetést.

Ellenőrizd a sikertelen párral, majd töltsd újra

Teszteld azt a két gazdagépet, amely valóban elbukott, a szükséges alkalmazással. Egy sikeres ping a munkaállomásodról a relay saját szolgáltatásához semmit sem bizonyít két másik partner közötti továbbításról, és ez a leggyakoribb téves pozitív az egész eljárásban.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Töltsd újra újraindítás helyett, és erősítsd meg, hogy a futó folyamat átvette a szerkesztett fájlt. Az újraindítás minden tunelt lebont, és nehezebben olvashatóvá teszi a következő tesztet, míg a SIGHUP megtartja a folyamatot, és újraolvastatja vele a konfigurációt:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

A systemctl reload csak akkor működik, ha a helyi unit definiálja az ExecReloadot, a projekttel szállított unit pedig nem teszi, ezért a systemctl kill -s HUP az a lépés, amely szabványos telepítésen sikerül. Az újratöltés után olvasd el a journalben azt a konfigurációs útvonalat, amelyet a folyamat megnyitott, hogy tudd, az új fájlt olvasta-e, és nem azt, amelyet feltételeztél betöltöttnek.

A relay-beállítások és a NAT-punch is az útvonalra hatnak; egyik sem hat az identitásra. Ha a pár továbbra is elbukik a kézfogáson, miután a am_relay, relays és use_relays megerősítést nyert a futó konfigurációban, ellenőrizd, hogy mindkét gazdagép olyan tanúsítványokat mutat-e be, amelyeket a beállított nevekre adtak ki, és hogy a CA ugyanaz-e mindkét oldalon. Tartsd rögzítve a tanúsítvány- és tűzfalkonfigurációt, miközben egyszerre egy átviteli beállítást változtatsz, mert egy tanúsítványmódosítás és egy relay-módosítás ugyanabban a tesztben semmit sem mond arról, melyikük mozdította el a kézfogást. A név- vagy CA-eltérés ugyanott bukik el, mint egy soha meg nem talált relay, ezért tartozik ez az ellenőrzés ugyanahhoz a menethez.

Ezután erősítsd meg, hogy minden nyilatkozat abban a fájlban van, amelyhez tartozik:

• am_relay: true a továbbító gazdagépen, és az a gazdagép mindkét oldalról elérhető UDP-n.
• relays: az adott gazdagép Nebula-címével a célon.
• use_relays: true a kapcsolatot indító partneren.
• Bejövő szabályok a célon, amelyek az útvonal változása után is engedélyezik a valódi forrást.