რატომ არ კვეთს მულტიკასტი VPN-ს გეგმის გარეშე

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

დაიწყეთ ჯგუფითა და აპლიკაციით

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

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

ლოკალური აღმოჩენა უნდა შეწყდეს

RFC 6762-ში აღწერილი Multicast DNS შექმნილია ერთი ბმულის გარშემო: მოთხოვნები მიდის ფიქსირებულ ჯგუფზე, პასუხები იგზავნება იმავე ჯგუფზე, და პროტოკოლი ეყრდნობა იმას, რომ ყველა მონაწილე ყველას ისმენს. მარშრუტიზატორები ნაგულისხმევად არ გადასცემენ ამ ტრაფიკს, და ეს დიზაინის გადაწყვეტილებაა და არა გამოტოვება. საზღვარი არსებობს იმისთვის, რომ ერთი შენობის მოწყობილობამ სხვაში თავისუფლად ვერ გამოაცხადოს თავი. გვირაბმა, რომელიც თითქოს აღმოჩენას ასწორებს ჯგუფის ყველგან ტარებით, მოხსნა ეს საზღვარი ყველა აპლიკაციისთვის და არა მხოლოდ იმისთვის, რომელსაც დახმარება სჭირდებოდა.

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

სამი რამ, რაც მარშრუტიზებულ მულტიკასტს სჭირდება

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

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

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

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

დაამტკიცეთ ერთი წყაროთი და ერთი მიმღებით

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

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

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

აირჩიეთ სერვისის მისამართი, როცა მხოლოდ სერვისი გჭირდებათ

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

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