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

ეს დროშა აცხადებს განზრახვას; ის ხელმისაწვდომობას არ ქმნის. რელე ხელმისაწვდომი უნდა იყოს ორივე პირისთვის, რაც პრაქტიკაში ნიშნავს საჯარო მისამართს, შემავალ UDP-ს Nebula პორტზე, გახსნილს ჰოსტის ფაირვოლში და ნებისმიერ ღრუბლოვან უსაფრთხოების ჯგუფში, და მის წინ ორმაგი 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.
• დანიშნულების შემავალი წესები გზის შეცვლის შემდეგაც ნამდვილ წყაროს უშვებს.