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 სახელი უნდა გადაწყდეს იმ რეზოლვერით, რომელიც ჰოსტს ნებისმიერი tunel-ის არსებობამდე აქვს, ანუ ჩვეულებრივი სისტემური რეზოლვერით. შეამოწმეთ ეს იმავე მანქანიდან, ჩატვირთვისას, overlay-ის გაჩერებული მდგომარეობით. სახელი, რომელიც მხოლოდ overlay-ის საკუთარი DNS-ით გადაწყდება, ვერ შეძლებს overlay-ის ბუტსტრაპს. იგივე ტესტი ეხება მარშრუტს: firewall-ის წესი, რომელიც overlay-ს უშვებს, მაგრამ არა პირველ UDP გაცვლას, ბლოკავს საწყის პაკეტს.

შეამოწმეთ პორტი UDP ხელსაწყოთი, ნაცვლად იმისა, რომ ღიად ჩათვალოთ. დაადასტურეთ, რომ გზაზე ნებისმიერი პორტის გადამისამართება სწორ შიდა ჰოსტს მიუთითებს და რომ დაბრუნების გზა არსებობს. თუ ჰოსტის სახელი რამდენიმე მისამართად გადაწყდება, შეამოწმეთ თითოეული, რადგან კლიენტმა შეიძლება აირჩიოს მისამართი, რომელიც არასდროს შემოწმებულა.

სტატიკური ჩანაწერები პირდაპირ იკრიფება და არასდროს ეკითხება შუქურას. ამიტომ აქ მარცხი ჩვეულებრივ დროის ამოწურვას ჰგავს პარტნიორის გარეშე.

რა ხდება პირველი ხელის ჩამორთმევის შემდეგ

როგორც კი ჰოსტი შუქურას მიაღწევს, ის პარტნიორებზე და მათ მისაწვდომ მისამართებზე ისწავლის დამატებითი ხელით ჩანაწერების გარეშე. ჰოსტები, რომლებიც ბოლო კავშირის შემდეგ გადაადგილდნენ, ამ არხის მეშვეობით აღმოსაჩენი ხდებიან. ეს არის ჯილდო ხელით რუკის პატარად შენახვისთვის.

ჰოსტებს ასევე შეუძლიათ გამოაცხადონ საკუთარი დამატებითი მისაწვდომი მისამართები, და ასე ეხმარება ცნობილი საჯარო მისამართის უკან მყოფი პარტნიორი სხვებს მის პოვნაში. ეს განცხადებები ისწავლება და არ იწერება სტატიკურ რუკაში.

განახლების ქცევა მნიშვნელოვანია DNS სახელებად დაწერილი ბოლო წერტილებისთვის, რადგან გადაწყვეტილი მისამართი შეიძლება შეიცვალოს, სანამ პროცესი განაგრძობს მუშაობას. Nebula-ს პარამეტრები აკონტროლებენ, როგორ ხდება ეს ძიებები, მათ შორის რომელი რეზოლვერი გამოიყენება, ამიტომ წაიკითხეთ ისინი და ნუ ჩათვლით სისტემურ ნაგულისხმევს. ჰოსტზე, რომლის რეზოლვერიც იცვლება tunel-ის აწევისას, არასწორმა პარამეტრმა შეიძლება მუშა ბუტსტრაპი გადააქციოს სახელად, რომელიც სესიის შუაში წყვეტს გადაწყვეტას. ძიების სტაბილურ რეზოლვერზე მიმაგრება ხშირად განსხვავებაა საიმედო overlay-სა და წყვეტილი overlay-ს შორის.

როცა აღმოჩენა მუშაობს, ერთი პარტნიორი კი არა

თუ შუქურები მისაწვდომია და პარტნიორების უმეტესობა უკავშირდება, ბუტსტრაპი პრობლემა არ არის. დარჩენილი წყვილი ან ერთმანეთთან გამოსაყენებელ გზას ვერ პოულობს, ან მისაწვდომობის ზემოთ ფარდება. შუქურას მისამართის კიდევ ერთი დაწერილობის დამატება ვერც ერთ შემთხვევას ვერ გამოასწორებს.

შეამოწმეთ წყვილი, სანამ შეასწორებთ რუკას, რომელსაც უკვე ყველაფერი ეყრდნობა. რუკის ცვლილება ყველა ჰოსტს აწუხებს, ამიტომ ეს ბოლო რამ არის, რასაც უნდა შეეხოთ, და არა პირველი.

დაიწყეთ იმავე ორგანოს სერტიფიკატებით, რადგან უარყოფილი ხელის ჩამორთმევა შორიდან შეიძლება მიუწვდომელ პარტნიორს ჰგავდეს. შემდეგ შეამოწმეთ, შეუძლია თუ არა წყვილს პირდაპირი გზის დამყარება და დაყენებულია თუ არა რელე იმ ქსელებისთვის, რომლებიც პირდაპირ ტრაფიკს უარყოფენ. რელე ამატებს ერთ ნახტომს და დამოკიდებულებას, მაგრამ ეს მხარდაჭერილი პასუხია, და წყვილის გზის გასწორება აღმოჩენის გასწორებისგან განსხვავებული ამოცანაა.