mDNS WireGuard-ზე: სამი კარიბჭე, სანამ თანატოლი უპასუხებს
Avahi-ს სჭირდება შესაფერისი ინტერფეისი, მარშრუტი ჯგუფამდე და თანატოლი, რომელიც ფლობს დანიშნულებას. სამი კარიბჭე, სამი ცალკე შემოწმება და არავითარი გაშლა.
WireGuard მოწყობილობაზე multicast დროშის დაყენება ინტერფეისს აქცევს აღმოჩენის პროგრამებისთვის შესაფერისს, და დროშა მხოლოდ ამას აკეთებს. ის არ ეუბნება პროტოკოლს, სად უნდა წავიდეს ჯგუფური პაკეტი, და რამდენიმე თანატოლის მქონე მოწყობილობაზე არც ერთი ცხადი პასუხი არ არსებობს. მუშა დემონსა და აღმოჩენილ სერვისს შორის სამი ცალკე კარიბჭე დგას.
შეამოწმეთ ისინი რიგრიგობით, რადგან ერთის გავლა შემდეგზე არაფერს გეუბნებათ.
პირველი კარიბჭე: დროშა და დემონის პოლიტიკა
Linux-ის WireGuard მოწყობილობა იქმნება როგორც წერტილ-წერტილ კავშირი ARP-ის გარეშე, და ნაგულისხმევად არ ატარებს multicast დროშას. დროშის დამატება ინტერფეისის ლოკალური ცვლილებაა, რომელსაც ასრულებს ის, რაც მოწყობილობას მართავს. Avahi-ს ამ ყველაფრის ზემოთ აქვს სამყაროს საკუთარი ხედვა, და მისი ნაგულისხმევი პოლიტიკა წერტილ-წერტილ ინტერფეისებს სრულიად გამოტოვებს. ამიტომ ერთი პაკეტის გადაადგილებამდე ორი დამოუკიდებელი ვარგისიანობის ტესტი მოქმედებს.
ამიტომ დემონს სჭირდება ცხადი გადაწყვეტილება და არა უბრალოდ მუშა პროცესი. მის დოკუმენტირებულ კონტროლებში შედის allow-interfaces, deny-interfaces და allow-point-to-point, და ბოლო არის ის პარამეტრი, რომელსაც ხალხი გამოტოვებს.
ქვემოთ მოცემული შემოწმებები აცხადებენ კავშირის დროშებს, multicast მარშრუტს და იმას, საერთოდ ანალიზდება თუ არა დემონის კონფიგურაცია:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkწარმატებით გაშვებულ დემონს სულაც არ გაუხსნია სოკეტები იმ ინტერფეისზე, რომელიც თქვენ გაინტერესებთ. წაიკითხეთ მისი ეფექტური კონფიგურაცია იმის ნაცვლად, რომ ჩათვალოთ სერვისის სტატუსი დაფარვის ტოლად.
მეორე კარიბჭე: მარშრუტი ჯგუფამდე
მეორე კარიბჭე ჩვეულებრივი მარშრუტიზაციაა. 224.0.0.251-ზე მისამართებული პაკეტი სხვა ყველაფრის მსგავსად მიჰყვება გადამისამართების ცხრილს, და თუ ცხრილი მას ფიზიკური LAN ინტერფეისით აგზავნის გარეთ, ვერც ერთი WireGuard კონფიგურაცია ვერ შეცვლის ამას. ჯერ მარშრუტი გაასწორეთ და დარჩენილი გამოძიება მოკლე გახდება. ნახეთ, რას აცხადებს ბირთვი ჯგუფის მისამართზე, სანამ რომელიმე თანატოლის გასაღებს შეეხებით.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
კონკრეტული მარშრუტის გარეშე ბირთვი უბრუნდება კავშირის საკუთარ multicast დამუშავებას, რის გამოც ნაგულისხმევი სწორად გამოიყურება ბრტყელ LAN-ზე და არასწორად მაშინვე, როცა იგივე ჯგუფური ტრაფიკი გვირაბით უნდა გავიდეს. წარუმატებლობა გამგზავნის მხრიდან ჩუმია: მოთხოვნა სადღაც მიდის და პასუხი არასდროს აღწევს.
მესამე კარიბჭე: WireGuard პაკეტზე ერთ თანატოლს ირჩევს
WireGuard გამავალ თანატოლს ირჩევს დანიშნულების ძებნით ნებადართული მისამართების სიმრავლეებში, და Linux-ის გადაცემის გზა ამ ძებნას ერთხელ ასრულებს თითო პაკეტზე. შედეგი ერთია და პაკეტი იშიფრება იმ თანატოლისთვის. იგივე ჯგუფური პრეფიქსი რამდენიმე თანატოლის ნებადართულ სიაში არ ქმნის წევრობას ან დუბლირებას; ის ქმნის ბუნდოვან ძებნას, რომელიც ერთ-ერთ მათგანზე წყდება.
ორი ბოლოს მქონე გამოყოფილ კავშირზე ეს ზუსტად ის არის, რაც გსურთ, რადგან განზრახ გადატანილი ჯგუფური ტრაფიკისთვის ერთი განკუთვნილი მიმღებია. ხუთი თანატოლის მქონე ინტერფეისზე ეს შეზღუდვაა და არა თვისება, და გასწორება დიზაინს ეკუთვნის და არა რომელიმე ერთი თანატოლის კონფიგურაციას.
გაშლილ დიზაინს სჭირდება ცხადი რელე, ცალკე კავშირები ან სრულიად სხვა აღმოჩენის მექანიზმი. ორი ბოლოს რეცეპტის მრავალკლიენტიან გადაწყვეტად გამოქვეყნება იმიტომ, რომ ყველა კლიენტს შეუძლია კარიბჭის ping-ი, სწორედ ის გზაა, რომლითაც ეს არასწორად თავსდება.
შემომავალი მიმართულება სხვანაირად მოწმდება: მიღებული პაკეტის წყარო უნდა მოხვდეს ავთენტიფიცირებული თანატოლის ნებადართულ სიაში. იქ multicast დანიშნულების დამატება არ ცვლის გამგზავნის ნამდვილ წყაროს მფლობელობას.
არეკვლა საზღვარია და არა ხიდი
Avahi-ს ამრეკლავი ამრავლებს mDNS შეტყობინებებს მის მიერ არჩეულ ინტერფეისებს შორის, გამოყენებით დონეზე. ეს არის აღმოჩენის საზღვარი ქსელებს შორის, არა Ethernet ხიდი და არა ზოგადი multicast მარშრუტიზატორი. ერთსა და იმავე ქსელებზე მიერთებული ორი ამრეკლავი სიამოვნებით შექმნის გამეორებული განცხადებების ციკლს.
არეკვლა ასევე გადასცემს სერვისების სახელებს და მათ მეტამონაცემებს სხვა ქსელს, რაც კონფიდენციალურობის გადაწყვეტილებაა ისევე, როგორც მარშრუტიზაციის. შეზღუდეთ არჩეული ინტერფეისები და გამოიყენეთ სერვისის ფილტრები იქ, სადაც დაყენებული ვერსია მათ მხარს უჭერს, რათა საზღვარი მხოლოდ უფლებამოსილი მომხმარებლისთვის საჭირო განცხადებებმა გადალახოს.
აღმოჩენა და გამოყენება ცალკე შედეგებად რჩება. კლიენტს შეუძლია დაინახოს სერვისის განცხადება, რომლის რეკლამირებული მისამართი მიუწვდომელია იქიდან, სადაც კლიენტი იმყოფება, ან რომლის პორტს მისი წვდომის პოლიტიკა უარყოფს. დაადასტურეთ სერვისთან კავშირი მას შემდეგ, რაც განცხადება გამოჩნდება, და თუ აპლიკაცია მხარს უჭერს სტაბილურ DNS სახელს ან ცხად სერვერის მისამართს, ამჯობინეთ ის კავშირის ლოკალური აღმოჩენის გაფართოებას. კრიპტოგასაღებით მარშრუტიზაციის აღწერა მოიცავს დანიშნულებაზე დაფუძნებულ თანატოლის არჩევანს, რომელზეც ეს ყველაფერი დგას.