Nebula static_host_map: հասցեն, որը փարոսը չի կարող տալ

Յուրաքանչյուր փարոս կարող է հոսթին պատմել ցանկացած այլ զուգընկերոջ մասին, բացի այն տեղից, որտեղ ինքը՝ փարոսը, գտնվում է։ Ինչ-որ բան պետք է հայտնի լինի մինչև overlay-ի գոյությունը, և Nebula-ն այդ ինչ-որ բանը դնում է մեկ փոքր քարտեզի մեջ։ Քարտեզը զուգակցում է overlay ինքնությունը սովորական ցանցում աշխատող հասցեի հետ։ Այն ամենը, ինչ սովորվում է ավելի ուշ, կախված է նրանից, որ այդ զուգակցումը ճիշտ լինի։

Երկու հասցե՝ երկու խնդիր

Յուրաքանչյուր Nebula հոսթ ունի overlay հասցե, որը մնում է հաստատուն, մինչ սարքը տեղափոխվում է ցանցերի միջև։ Այդ հասցեն այն ինքնությունն է, որն օգտագործում են վկայագրերը, firewall-ի կանոնները և զուգընկերային հարաբերությունները, և ինքնուրույն այն ոչ մի տեղ չի երթուղավորում։ Հասանելի վերջնակետը այլ բան է՝ հոսթի անուն կամ հասցե ստորին ցանցում գումարած UDP պորտ, և այն փոխվում է ամեն անգամ, երբ մեքենան փոխում է տեղը։ Ստատիկ քարտեզը երկուսի միջև կապն է։

Քարտեզի մեջ մտնում են միայն այն հոսթերը, որոնք պետք է սառը հավաքվեն, ինչը սովորաբար նշանակում է փարոսները և գուցե մեկ ռելե։ Այդ ցանկը կարճ պահելը դիզայնի նպատակ է, որովհետև յուրաքանչյուր ձեռքով գրառում դառնում է փաստ, որ ինչ-որ մեկը պետք է պահպանի։ Երկու հասցեատեսակների շփոթումը սովորական կազմաձևման սխալ է. փարոսների ցանկում դրված հանրային հասցեն չի սկսում հայտնաբերումը։

Ինքնությունը գնում է այնտեղ, որտեղ ինքնություն է սպասվում։ Հասանելիությունը գնում է քարտեզ։

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Քարտեզի գրառման կառուցվածքը

Բանալին overlay հասցեն է՝ գրված որպես չակերտների մեջ տող, իսկ արժեքը վերջնակետերի ցանկ է, այնպես որ մեկ ինքնությունը կարող է ունենալ մի քանի մուտքի կետ։ Յուրաքանչյուր վերջնակետ կրում է հոսթ և պորտ, և պորտը պետք է համապատասխանի նրան, ինչին մյուս կողմն իրականում լսում է։ Nebula-ի լռելյայնը UDP 4242-ն է, որը ելակետ է, ոչ թե խոստում ձեր տեղակայման մասին։

Մի քանի վերջնակետ օգտակար են, երբ փարոսն ունի ներս մտնելու մեկից ավելի ուղի, օրինակ հանրային հասցե և մասնավոր հասցե նույն սեգմենտի հոսթերի համար։ Հաճախորդը փորձում է դրանք հերթով, ուստի ամենահուսալին դրեք առաջինը։ IPv6-ի համար հասցեն դրեք քառակուսի փակագծերի մեջ՝ նախքան պորտը ավելացնելը. սխալվելը տալիս է վերլուծության սխալ, որը ցույց է տալիս սխալ տողը։

Սխալ պորտը լռություն է տալիս սխալի փոխարեն, որովհետև UDP-ն չունի մերժելու ձեռքսեղմում։ Դրա համար արժե գրառման ձևաչափը ստուգել Nebula-ի static_host_map տեղեկատուի հետ, ոչ թե հիշողության։ Տեղեկատուն ներառում է նաև վերջնակետերի ցանկեր և DNS-ի թարմացման վարքագիծ։

Բունսթրեփը պետք է աշխատի overlay-ից առաջ

Քարտեզում DNS անունը պետք է լուծվի այն լուծիչով, որ հոսթն ունի մինչև ցանկացած թունելի գոյությունը, այսինքն՝ սովորական համակարգային լուծիչով։ Փորձարկեք դա նույն մեքենայից, բեռնման պահին, overlay-ը կանգնեցված։ Անունը, որը լուծվում է միայն overlay-ի սեփական DNS-ով, չի կարող բունսթրեփել overlay-ը։ Նույն փորձարկումը վերաբերում է երթուղուն. firewall-ի կանոնը, որը թույլ է տալիս overlay-ը, բայց ոչ առաջին UDP փոխանակումը, արգելափակում է սկզբնական փաթեթը։

Ստուգեք պորտը UDP գործիքով՝ փոխարենը ենթադրելու, որ այն բաց է։ Հաստատեք, որ ուղու ցանկացած պորտային վերահասցեավորում ուղղված է ճիշտ ներքին հոսթին, և որ վերադարձի ուղի գոյություն ունի։ Եթե հոսթի անունը լուծվում է մի քանի հասցեների, փորձարկեք յուրաքանչյուրը, որովհետև հաճախորդը կարող է ընտրել հասցե, որը երբեք չեք ստուգել։

Ստատիկ գրառումները հավաքվում են ուղղակիորեն և երբեք չեն խորհրդակցում փարոսի հետ։ Դրա համար այստեղ ձախողումը նման է սովորական ժամկետի սպառման՝ առանց որևէ զուգընկերոջ։

Ինչ է պատահում առաջին ձեռքսեղմումից հետո

Հենց հոսթը հասնում է փարոսին, այն իմանում է զուգընկերների և նրանց հասանելի հասցեների մասին՝ առանց լրացուցիչ ձեռքով գրառումների։ Այն հոսթերը, որոնք տեղափոխվել են վերջին կապից հետո, դառնում են հայտնաբերելի այդ ալիքով։ Սա է ձեռքով քարտեզը փոքր պահելու պարգևը։

Հոսթերը կարող են նաև հայտարարել իրենց լրացուցիչ հասանելի հասցեները, և այդպես հայտնի հանրային հասցեի հետևում գտնվող զուգընկերը օգնում է ուրիշներին գտնել իրեն։ Այդ հայտարարությունները սովորվում են, ոչ թե գրվում ստատիկ քարտեզի մեջ։

Թարմացման վարքագիծը կարևոր է DNS անուններով գրված վերջնակետերի համար, որովհետև լուծված հասցեն կարող է փոխվել, մինչ գործընթացը շարունակվում է։ Nebula-ի կարգավորումները ղեկավարում են, թե ինչպես են այդ որոնումները կատարվում, ներառյալ, թե որ լուծիչն է օգտագործվում, ուստի կարդացեք դրանք՝ փոխարենը ենթադրելու համակարգի լռելյայնը։ Այն հոսթում, որի լուծիչը փոխվում է, երբ թունելը բարձրանում է, սխալ կարգավորումը կարող է աշխատող բունսթրեփը դարձնել անուն, որ դադարում է լուծվել նստաշրջանի կեսին։ Որոնումը կայուն լուծիչին կապելը հաճախ վստահելի overlay-ի և ընդմիջումներով աշխատողի միջև եղած տարբերությունն է։

Երբ հայտնաբերումն աշխատում է, իսկ մեկ զուգընկեր՝ ոչ

Եթե փարոսները հասանելի են, և զուգընկերների մեծ մասը միանում է, բունսթրեփը խնդիրը չէ։ Մնացած զույգը կամ չի գտնում օգտագործելի ուղի միմյանց, կամ ձախողվում է հասանելիությունից վեր։ Փարոսի հասցեի ևս մեկ գրելաձև ավելացնելը չի կարող ուղղել երկու դեպքերից ոչ մեկը։

Ստուգեք զույգը նախքան այն քարտեզը խմբագրելը, որի վրա արդեն հենվում է մնացած ամեն ինչ։ Քարտեզի փոփոխությունը խանգարում է յուրաքանչյուր հոսթի, ուստի այն վերջին բանն է, որին պետք է դիպչել, ոչ առաջինը։

Սկսեք նույն իշխանության վկայագրերից, որովհետև մերժված ձեռքսեղմումը հեռվից կարող է թվալ անհասանելի զուգընկեր։ Ապա ստուգեք՝ կարո՞ղ է զույգը ուղիղ ուղի հաստատել, և արդյոք ռելե է կարգավորված ուղիղ երթևեկությունը մերժող ցանցերի համար։ Ռելեն ավելացնում է մեկ թռիչք և կախվածություն, բայց դա աջակցվող պատասխան է, և զույգի ուղին ուղղելը տարբեր խնդիր է հայտնաբերումը ուղղելուց։