Nebula: реле тохируулагдсан боловч ашиглагдахгүй байна — шалгах гурван тохиргоо

Реле замын хувьд гурван хост дээрх гурван мэдэгдэл тохирох ёстой. Эхлээд реле үүрэг, очих газрын реле жагсаалт, хийрийн зөвшөөрлийг шалгана уу.

Та реле хост нэмж, түүний Nebula хаягийг тохиргоонд оруулсан боловч хоёр хийр одоо ч ярилцахгүй байна. Энэ нь реле замд гурван тусдаа мэдэгдэл тохирох шаардлагатай бөгөөд тэдгээрийн зөвхөн нэг нь таны зассан машинд байдагтай холбоотой. Би үүнийг хоёр удаа мөрдсөн: нэг удаа дамжуулах хостод реле үүрэг огт өгөөгүй байсан, нөгөө удаа тохиргоог холболтын буруу талд бичсэн байсан. Доорх дараалал нь үүрэг, зарлал, зөвшөөрлийг энэ дарааллаар шалгах бөгөөд алхам бүрт үргэлжлүүлэх эсэхийг хэлэх команд байна.

Тохиргоог засахын өмнө гурван үүргийг зур

Nebula хост бүрд нэг ажил өгдөг бөгөөд ажлууд өвлөгддөггүй. Гэрэлт цамхаг «энэ хийр хаана байна» гэсэн асуултад хариулж, хостүүд бие биеэ олох боломжтой болгоно. Реле ажиллах шууд замгүй хоёр хийрийн хооронд урсгалыг дамжуулна. Энгийн хост хоёуланг нь хийдэггүй. Чухал гурван тохиргоо гурван өөр машин дээр байдаг тул бүрэн харагдах клиент тохиргоо хоёр хийрийг хоёуланг нь хүлээлгэж болно.

# 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

Нэг шинж тэмдэг нь хоёр төрлийн алдааг ялгана. Хэрэв хоёр хийр бие биеэ жагсааж, лог нь хэзээ ч дуусахгүй гар барилтын оролдлогыг харуулж байвал нээлт ажиллаж байгаа бөгөөд өгөгдлийн замыг NAT эсвэл галт хана хаасан байна. Хэрэв хийр нөгөөгийнхөө хаягийг огт мэдэхгүй бол асуудал гэрэлт цамхаг эсвэл түүний статик хост зурагт байгаа бөгөөд реле тохиргоо үүнийг засахгүй.

Өөр юу ч засахаас өмнө хост бүр яг ямар тохиргоог ачаалсныг баталгаажуулна уу. Таны зассан файлаас өөр замыг уншдаг юнит «өөрчлөлт юу ч хийсэнгүй» гэдгийн нийтлэг бөгөөд ичмээр шалтгаан:

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

Холимог паркт хувилбарын мөр чухал. Реле боловсруулалт, цооролтын зан төлөв, хүлээн авдаг тохиргооны түлхүүрүүд хувилбаруудын хооронд ижил биш тул хуучин бүтээц өөрт нь бичээгүй хэсгийг ойлгоно гэж бүү бодоорой. Хостүүдийг нэг жижиг цувралд тэгшлээд, дараа нь хост бүр дээр nebula -test -config /etc/nebula/config.yml ажиллуулж, код хэрэгжүүлээгүй тээврийг дибаг хийхээс өмнө гаралтыг харьцуулна уу.

Реле хост дээр дамжуулах үүргийг идэвхжүүлнэ үү

Реле үүрэг нь дамжуулах хост дээрх нэг туг бөгөөд гэрэлт цамхаг байхээс тусдаа. Нээлт идэвхтэй, реле дамжуулалт идэвхгүй хост нь зөвхөн нээлтийн үйлчилгээ хэвээр. Реле дээр:

relay:
  am_relay: true

Энэ туг зорилгыг зарладаг; хүртээмж үүсгэдэггүй. Реле хоёр хийрээс хүртээмжтэй байх ёстой бөгөөд энэ нь бодит байдал дээр нийтийн хаяг, хостны галт ханан дахь болон аливаа үүлэн аюулгүй байдлын бүлэг дэх Nebula порт дээрх нээлттэй ирж буй UDP, мөн өмнө нь давхар NAT байхгүй байхыг хэлнэ. Сонсож буй сокетыг шалгаад, дараа нь хийрийн пакетууд ирж буйг ажиглана уу:

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

Хоёр хязгаар дараа нь цаг хэмнэнэ. Реле рүү өөр релеэр хүрэх боломжгүй тул тохиргоон дахь реле нэрсийн гинжин хэлхээ нь дамжуулах хостод ашигтай зам өгөхийг орлохгүй. Мөн реле пакетуудыг дамжуулдаг; зөвшөөрөл өгдөггүй тул релеэр дамжсан урсгалд зөвшөөрөл өгсөн эсэхийг очих газрын өөрийн ирж буй дүрмүүд шийднэ. Үүрэг болон түүний шаардлагыг реле тохиргооны баримт бичигт тайлбарласан.

Релег клиентээс биш, очих газраас зарлана уу

Энэ бол хамгийн их цаг иддэг урвуу байдал. Реле жагсаалт нь таны хүрэхийг оролдож буй хост дээр байх ёстой, учир нь энэ нь бусад хийрүүдэд тухайн хостод хүрэхийн тулд ямар реле ашиглаж болохыг хэлдэг. Үүнийг холболт эхлүүлж буй клиент дээр тавих нь клиентэд хэрэгтэй чиглэлд юу ч хийдэггүй:

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

Хийрүүд гэрэлт цамхагт бүртгүүлэхдээ өөрсдийн хаягийн хамт энэ жагсаалтыг мэдээлдэг тул зарлал шууд солилцоогоор бус нээлтээр тархдаг. Хэрэв очих газар ямар ч гэрэлт цамхагт хүрч чадахгүй бол түүний реле жагсаалт хэзээ ч тархахгүй бөгөөд зөв тохируулсан реле сул зогсоно. Тэр алдаа нь эвдэрсэн релетэй яг адил харагдана, гэхдээ тийм биш.

Мөн энэ алхамд очих газарт ачааллын зам өгнө үү. Статик хост зураг нь Nebula хаягийг нийтийн төгсгөлийн цэгтэй холбож, эхний гар барилт явах газартай болгоно, мөн очих газар шууд хүрч чадахгүй хостүүдээс релеэр дамжсан урсгалыг хүлээн авах бол релеийн бичлэг хэрэгтэй:

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

Холбогдож буй хийрт реле ашиглахыг зөвшөөрнө үү

Эхлүүлж буй тал өөрийн зөвшөөрөл хэрэгтэй. relay.use_relays анхдагчаар асаалттай тул хайх үнэ цэнэтэй тохиолдол бол тодорхой false бөгөөд энэ нь ихэвчлэн реле функц үүсэхээс өмнө бичсэн загвараас хуулагдсан эсвэл шууд замыг албадах өмнөх оролдлогоос үлдсэн байдаг:

relay:
  use_relays: true

Энэ талын зөвшөөрөл цорын ганц хаалга биш. Очих газрын ирж буй дүрмүүд релеэр дамжсан пакетэд ч хүчинтэй бөгөөд тэдгээрийн тааруулдаг эх сурвалж нь релений өөрийн хаяг бус, туннель доторх таних тэмдэг юм. Релеэр дамжсан гар барилт дууссаны дараа ч програб ажиллахгүй бол дүрмийг дахин бичихээс өмнө очих газрын логоос бүртгэсэн эх сурвалжийг уншина уу.

NAT дамжуулах тохиргоо энэ бүхэнтэй харилцан үйлчилдэг. punchy.punch хоёр хийрт шууд зам нээхэд тусалдаг бөгөөд энэ нь амжилттай болбол ажиглах реле урсгал байхгүй; энэ нь амжилт, алга болсон реле биш. Завсарлагатай ажилладаг хос нь ихэвчлэн цооролт заримдаа амжилттай байдаг гэсэн үг тул нэг оролдлогоос дүгнэлт хийхгүйгээр тэр хосыг хэд хэдэн удаа туршина уу.

Алдсан хосоор шалгаад, дараа нь дахин ачаална уу

Бодитоор алдсан хоёр хостдыг тэдэнд хэрэгтэй програмын хамт туршина уу. Ажлын станцаас релений өөрийн үйлчилгээ рүү амжилттай ping хийх нь бусад хоёр хийрийн хоорондын дамжуулалтын талаар юу ч батлахгүй бөгөөд энэ нь энэ бүх процедурын хамгийн түгээмэл хуурамч эерэг үр дүн.

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

Дахин эхлүүлэхийн оронд дахин ачаалж, ажиллаж буй процесс таны зассан файлыг авсныг баталгаажуулна уу. Дахин эхлүүлэх нь бүх туннелийг эвдэж, дараагийн туршилтыг уншихад хэцүү болгодог бол SIGHUP процессыг хадгалж, тохиргоог дахин уншихад хүргэдэг:

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

systemctl reload нь локал юнит ExecReload тодорхойлсон үед л ажилладаг бөгөөд төсөлтэй хамт ирдэг юнит үүнийг тодорхойлдоггүй тул стандарт суулгацад амжилттай болох алхам нь systemctl kill -s HUP. Дахин ачаалсны дараа процесс нээсэн тохиргооны замд зориулж журналыг уншина уу, таны таамагласан файл биш, шинэ файл уншигдсаныг мэдэхээр.

Реле тохиргоо болон NAT цооролт хоёулаа замд үйлчилдэг; аль нь ч таних тэмдэгт үйлчилдэггүй. Ажиллаж буй тохиргоонд am_relay, relays болон use_relays батлагдсаны дараа ч хос гар барилтад алдвал хоёр хост тохируулсан нэрсдээ зориулж олгосон гэрчилгээг үзүүлж байгаа эсэх, хоёр талд CA ижил эсэхийг шалгана уу. Гэрчилгээ болон галт ханын тохиргоог хөдөлгөөнгүй байлгаж, нэг удаад нэг тээврийн тохиргоог өөрчилнө үү, учир нь нэг туршилтад орсон гэрчилгээний засвар болон релений засвар аль нь гар барилтыг хөдөлгөснийг хэлэхгүй. Нэр эсвэл CA тохирохгүй байх нь хэзээ ч олдоогүй релетэй нэг газарт алддаг тул энэ эсрэг шалгалт мөн адил алхамд хамаарна.

Дараа нь мэдэгдэл бүр өөрийн файлд байгаа эсэхийг баталгаажуулна уу:

  • Дамжуулах хост дээрх am_relay: true болон тэр хост хоёр талаас UDP-ээр хүртээмжтэй байх.
  • Очих газарт тэр хостны Nebula хаягийг нэрлэсэн relays:.
  • Холболт эхлүүлж буй хийр дээрх use_relays: true.
  • Зам өөрчлөгдсөний дараа ч очих газрын ирж буй дүрмүүд бодит эх сурвалжид зөвшөөрөл өгдөг.

Холбоотой нийтлэлүүд