Nebula advertise_addrs თუ static_host_map: აირჩიეთ მფლობელის მიხედვით
სტატიკურ რუკას ინახავს ყოველი peer, რომელიც მას უკავშირდება; გამოცხადებულ მისამართს ჰოსტი აქვეყნებს. აირჩიეთ იმის მიხედვით, თუ ვინ იცის საბოლოო წერტილი.
static_host_map და advertise_addrs ორივე აყენებს მისამართს peer-ის წინ და პასუხობს სხვადასხვა კითხვას. ერთი ლოკალური ფაილია, რომელიც ჩამოთვლის overlay მისამართს და დასაკავშირებელ underlay საბოლოო წერტილს. მეორე ჰოსტია, რომელიც თავის შუქურებს ეუბნება, რომელი დამატებითი საბოლოო წერტილები შეუძლია მიაღწიოს მას. ნამდვილი განსხვავება საკუთრებაა: რუკას ინახავს ყველა, ვისაც ის სჭირდება, ხოლო განცხადებას თავად ჰოსტი.
გადაწყვიტეთ იმის მიხედვით, თუ ვის ეკუთვნის ინფორმაცია
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
ყოველი ცვალებადი peer ყოველი peer-ის სტატიკურ ფაილში არის მოვლის სამუშაო, რომელიც ფლოტის კვადრატით იზრდება. ეს არის პრაქტიკული მიზეზი, რომ მივმართოთ მეორე პარამეტრს, როცა თავად ჰოსტმა იცის პასუხი.
საკუთრების კითხვა ასევე წინასწარმეტყველებს, რა ხდება მისამართის შეცვლისას. სტატიკური რუკის შემთხვევაში ვინმემ უნდა დაიმახსოვროს ყოველი peer, რომელსაც ძველი ჩანაწერი აქვს. განცხადების შემთხვევაში ჰოსტი აქვეყნებს ახალ საბოლოო წერტილს და მისი შუქურები გადასცემენ მას, ამიტომ ცვლილება რჩება ლოკალური გადაადგილებულ მანქანაზე.
Bootstrap-ს მაინც სჭირდება სტატიკური ჩანაწერები
კლიენტმა უნდა მიაღწიოს სულ მცირე ერთ შუქურას, სანამ ვინმეს ჰკითხავს სხვა peer-ებზე. ეს პირველი ნახტომი ვერ მოვა აღმოჩენიდან, ამიტომ საჭიროა სტატიკური ჩანაწერი კლიენტის კონფიგურაციაში. გაასწორეთ ეს ერთი ჩანაწერი და overlay-ის დანარჩენი ნაწილის სწავლა შესაძლებელი გახდება.
რუკის ჩანაწერი აკავშირებს Nebula მისამართს ერთ ან მეტ მისაწვდომ IP ან DNS საბოლოო წერტილსა და პორტთან. შუქურების იქ შენახვა ნორმალურია; ყოველი peer-ის იქ შენახვა ის ნიმუშია, რომელიც ცუდად ბერდება, რადგან ყოველი ახალი peer ნიშნავს ფაილების რედაქტირებას იმ მანქანებზე, რომლებსაც შეიძლება არ აკონტროლებდეთ. შეინახეთ სია საკმარისად მოკლე, რომ ადამიანმა ჯერ კიდევ შეძლოს მისი გადამოწმება წაკითხვით.
გამოაცხადეთ, როცა ჰოსტმა იცის საბოლოო წერტილი
პორტების გადაგზავნის უკან მყოფი ჰოსტი ხელმისაწვდომია საჯარო მისამართზე, რომელიც არც ერთ მის ინტერფეისს არ არის მინიჭებული. მას არ შეუძლია ამ მისამართის აღმოჩენა საკუთარი თავის ყურებით. advertise_addrs საშუალებას აძლევს მას გამოაქვეყნოს საბოლოო წერტილი თავისი შუქურების მეშვეობით, რათა სხვა peer-ებმა ისწავლონ გზა, რომელიც ნამდვილად მუშაობს. პარამეტრი არსებობს ზუსტად იმიტომ, რომ ჰოსტი ერთადერთი მხარეა, რომელმაც იცის, რომ რუკების შედგენა მოხდა.
გამოიყენეთ ის მისამართი და პორტი, რომლებზეც სხვა peer-ებს ნამდვილად შეუძლიათ მისვლა. იგივე მსჯელობა ეხება ჰოსტს, რომელსაც რამდენიმე ქსელური გზა აქვს, სადაც ერთი გზა სასურველია კონკრეტული ქსელის peer-ებისთვის. განცხადება არის განაცხადი underlay-ზე, არა მოთხოვნა რაიმეზე. როცა რუკება იცვლება, განაახლეთ განცხადება ჰოსტზე და მიეცით აღმოჩენას მისი გადატანის საშუალება, მთელ ფლოტში სტატიკური ფაილების რედაქტირების ნაცვლად.
განცხადება ხელმისაწვდომობა არ არის
საბოლოო წერტილის გამოქვეყნება არ ქმნის მარშრუტიზატორის გადაგზავნის წესს, არ ხსნის ზედა firewall-ს და არ იწვევს DNS სახელის ამოხსნას. ეს სამუშაოს ცალკეული ნაწილებია, და დაკარგული პორტის გადაგზავნით სწორი განცხადება წარმოქმნის ზუსტად იმ მარცხს, რომლის გამოსწორებასაც ცდილობდით. განცხადება არის მტკიცება ხელმისაწვდომობაზე, არა მექანიზმი, რომელიც ამყარებს მას.
შეამოწმეთ გზა გარედან, სანამ აღმოჩენას დაადანაშაულებთ. peer-ს, რომელიც სწავლობს საბოლოო წერტილს, მაგრამ ვერ ასრულებს handshake-ს, აქვს მარშრუტიზაციის ან ფილტრაციის პრობლემა underlay-ზე, და იმავე მისამართის ორივე პარამეტრში გამეორება ამას არ შეცვლის.
შეინახეთ overlay მისამართი საბოლოო წერტილისგან ცალკე
კვანძის სერტიფიკატი იდენტიფიცირებს მის Nebula მისამართს. გამოცხადებული მისამართები ეკუთვნის ქვედა ქსელს და შეიძლება შეიცვალოს სერტიფიკატზე შეხების გარეშე. ახალი სერტიფიკატის გაცემა სხვა overlay IP-ით სხვა ოპერაციაა, თავისი შედეგებით ყოველი ნდობის ურთიერთობისთვის, რომელმაც ძველი დააფიქსირა. შეინახეთ ორი ცვლილება ცალკე runbook-ში, თორემ საბოლოო წერტილის გადატანა ჩაიწერება როგორც ხელახალი გაცემა.
როცა triage ჩერდება, ცხადად გაყავით ორი ფენა: აბრუნებს აღმოჩენა მოსალოდნელ საბოლოო წერტილს და აღწევს მას handshake? თუ აღმოჩენა სწორია და პაკეტები ვერ გადის, პრობლემა overlay-ის ქვემოთაა. თუ აღმოჩენა არასწორია, პრობლემა რუკაში ან განცხადებაშია, და გასწორება იქ ეკუთვნის.