Nebula relesi konfiqurasiya edilib, amma istifadə olunmur: yoxlanmalı üç parametr

Siz relay hostu əlavə etdiniz, onun Nebula ünvanını konfiqurasiyaya yazdınız, amma iki peer yenə də bir-biri ilə danışmır. Bu ona görə olur ki, relay marşrutu üç ayrı ifadənin uzlaşmasını tələb edir və onlardan yalnız biri çox güman ki sizin redaktə etdiyiniz maşında yerləşir. Mən bu işin arxasınca iki dəfə düşmüşəm: bir dəfə yönləndirici hosta relay rolu heç vaxt verilməmişdi, bir dəfə isə parametrlər bağlantının yanlış tərəfində yazılmışdı. Aşağıdakı ardıcıllıq rolu, elanı və icazəni bu sıra ilə yoxlayır və hər addımın davam edib-etməməyinizi deyən bir əmri var.

Konfiqurasiyanı redaktə etməzdən əvvəl üç rolu xəritələyin

Nebula hər hosta bir vəzifə verir və vəzifələr miras alınmır. Mayak «bu peer haradadır» suallarına cavab verir ki, hostlar bir-birini tapa bilsin. Relay işlək birbaşa marşrutu olmayan iki peer arasında trafiki yönləndirir. Adi host ikisini də etmir. Vacib olan üç parametr üç fərqli maşında yerləşir, buna görə də tam görünən bir client konfiqurasiyası hər iki peer-i gözləməkdə qoya bilər.

# 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

İki nasazlıq sinfini bir simptom ayırır. Əgər hər iki peer bir-birini siyahıya salırsa və jurnal heç vaxt tamamlanmayan handshake cəhdləri göstərirsə, kəşfiyyat işləyir, məlumat yolu isə NAT və ya firewall tərəfindən bağlanıb. Əgər peer digər ünvanı heç öyrənmirsə, problem mayakda və ya onun statik host xəritəsindədir və relay parametrləri bunu düzəldə bilməz.

Hər hansı başqa dəyişiklik etməzdən əvvəl hər hostun faktiki olaraq hansı konfiqurasiyanı yüklədiyini təsdiqləyin. Redaktə etdiyiniz fayldan fərqli yol oxuyan unit «dəyişiklik heç nə etmədi» mesajının geniş yayılmış və utancverici səbəbidir:

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

Versiya sətri qarışıq parkda vacibdir. Relay emalı, punch davranışı və qəbul edilən konfiqurasiya açarları buraxılışlar arasında eyni deyil, ona görə də köhnə build-in yazılmadığı bölməni başa düşdüyünü güman etməyin. Hostları eyni minor seriyasına uyğunlaşdırın, sonra hər hostda nebula -test -config /etc/nebula/config.yml işə salın və kodun həyata keçirmədiyi nəqli sazlamağa başlamazdan əvvəl çıxışları müqayisə edin.

Relay hostunda yönləndirmə rolunu aktivləşdirin

Relay rolu yönləndirici hostda bir bayraqdır və mayak olmaqdan ayrıdır. Kəşfiyyat aktiv, relay yönləndirməsi deaktiv olan host yenə də yalnız kəşfiyyat xidmətidir. Relaydə:

relay:
  am_relay: true

Bu bayraq niyyəti bildirir; əlçatanlıq yaratmır. Relay hər iki peer-dən əlçatan olmalıdır, bu da praktikada publik ünvan, host firewallunda və hər hansı bulud təhlükəsizlik qrupunda Nebula portunda açıq gələn UDP və qarşısında ikiqat NAT olmaması deməkdir. Dinləyən soketi yoxlayın, sonra peer-in paketlərinin gəlişini izləyin:

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

İki məhdudiyyət sonradan vaxt qazandırır. Relay-a başqa relay vasitəsilə çatmaq mümkün deyil, ona görə də konfiqurasiyada relay adları zənciri yönləndirici hosta işlək yol verməyin əvəzi deyil. Və relay paketləri yönləndirir; icazə vermir, buna görə də yönləndirilən axına icazə verilib-verilmədiyini yenə də təyinatın öz gələn qaydaları həll edir. Rol və onun tələbləri relay konfiqurasiyası sənədində göstərilib.

Relay-ı clientdən deyil, təyinatdan elan edin

Ən çox saat yeyən şey bu tərsinəlikdir. Relay siyahısı çatmaq istədiyiniz hostda olmalıdır, çünki o, digər peer-lərə hansı relay-ların həmin hosta çatmaq üçün istifadə oluna biləcəyini deyir. Onu bağlantını başladan clientə qoymaq clientin ehtiyac duyduğu istiqamət üçün heç nə etmir:

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

Peer-lər mayakla əlaqə saxlayarkən bu siyahını ünvanları ilə birlikdə bildirir, buna görə də elan birbaşa mübadilə ilə deyil, kəşfiyyat vasitəsilə yayılır. Əgər təyinat mayaka çata bilmirsə, onun relay siyahısı heç vaxt yayılmır və düzgün konfiqurasiya edilmiş relay boş qalır. Bu nasazlıq sınıq relay kimi görünür, amma sınıq deyil.

Eyni gedişdə təyinata bootstrap yolu verin. Statik host xəritəsi Nebula ünvanını publik endpoint-ə bağlayır ki, ilk handshake-in gedəcəyi yer olsun və təyinat birbaşa çata bilmədiyi hostlardan yönləndirilmiş trafiki qəbul edəcəksə, onun relay üçün bir girişə ehtiyacı var:

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

Qoşulan peer-ə relay-dan istifadə etməyə icazə verin

Başladan tərəf öz icazəsinə ehtiyac duyur. relay.use_relays defolt olaraq aktivdir, ona görə də axtarmağa dəyər hal açıq false-dır, çox vaxt relay funksiyası yaranmazdan əvvəl yazılmış şablondan köçürülür və ya birbaşa yolları məcbur etmək üçün əvvəlki cəhddən qalır:

relay:
  use_relays: true

Bu tərəfdəki icazə yeganə qapı deyil. Təyinatın gələn qaydaları yönləndirilmiş paketə hələ də tətbiq olunur və uyğunlaşdırdıqları mənbə relay-ın öz ünvanı deyil, tunelin içindəki kimlikdir. Yönləndirilmiş handshake tamamlananda və tətbiq yenə də uğursuz olanda, qaydanı yenidən yazmazdan əvvəl təyinatın jurnalında qeyd etdiyi mənbəni oxuyun.

NAT keçid parametrləri bütün bunlarla qarşılıqlı təsirdədir. punchy.punch iki peer-ə birbaşa yol açmağa kömək edir və o uğur qazandıqda müşahidə ediləcək relay trafiki olmur; bu uğurdur, itkin relay deyil. Aralıq işləyən cüt adətən punch-ın bəzən uğur qazandığını bildirir, ona görə də bir cəhddən nəticə çıxarmaq əvəzinə o cütü bir neçə dəfə sınaqdan keçirin.

Uğursuz olan cütlə yoxlayın, sonra yenidən yükləyin

Faktiki olaraq uğursuz olan iki hostu, ehtiyac duyduqları tətbiqlə sınaqdan keçirin. İş stansiyanızdan relay-ın öz xidmətinə uğurlu ping digər iki peer arasındakı yönləndirmə haqqında heç nə sübut etmir və bu, bütün prosedurda ən çox rast gəlinən yalançı müsbətdir.

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

Yenidən işə salmaq əvəzinə yenidən yükləyin və işləyən prosesin redaktə etdiyiniz faylı götürdüyünü təsdiqləyin. Yenidən işə salma hər tuneli dağıdır və növbəti testi oxumağı çətinləşdirir, SIGHUP isə prosesi saxlayır və konfiqurasiyanı yenidən oxutdurur:

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

systemctl reload yalnız lokal unit ExecReload təyin etdikdə işləyir və layihə ilə gələn unit bunu etmir, buna görə də standart quraşdırmada uğur qazanan addım systemctl kill -s HUP-dir. Yenidən yükləmədən sonra prosesin açdığı konfiqurasiya yolu üçün jurnalı oxuyun ki, güman etdiyiniz faylın deyil, yeni faylın oxunduğunu biləsiniz.

Relay parametrləri və NAT punch ikisi də yola təsir edir; heç biri kimliyə təsir etmir. Əgər am_relay, relays və use_relays işləyən konfiqurasiyada təsdiqləndikdən sonra cüt hələ də handshake-də uğursuz olursa, hər iki hostun konfiqurasiya olunduqları adlar üçün verilmiş sertifikatlar təqdim etdiyini və hər iki tərəfdə CA-nın eyni olduğunu yoxlayın. Sertifikat və firewall konfiqurasiyasını sabit saxlayın, eyni anda yalnız bir nəql parametrini dəyişin, çünki eyni testdə baş verən sertifikat düzəlişi və relay düzəlişi handshake-i hansının hərəkətə gətirdiyini demir. Ad və ya CA uyğunsuzluğu heç vaxt tapılmayan relay ilə eyni yerdə uğursuz olur, buna görə də bu əks yoxlama eyni gedişə aiddir.

Sonra hər ifadənin aid olduğu faylda olduğunu təsdiqləyin:

• am_relay: true yönləndirici hostda və həmin host hər iki tərəfdən UDP ilə əlçatan olsun.
• relays: təyinatda həmin hostun Nebula ünvanını göstərsin.
• use_relays: true bağlantını başladan peer-də olsun.
• Təyinatdakı gələn qaydaları yol dəyişdikdən sonra da real mənbəyə icazə verir.