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։
• Նպատակակետի մուտքային կանոնները ուղին փոխվելուց հետո էլ թույլ են տալիս իրական աղբյուրին։