SSM OpenVPN-ზე: ერთი წყაროსა და ჯგუფის თვალყურის დევნება დასაწყისიდან ბოლომდე

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

ჯერ წყარო, ჯგუფი და მიმღები დააფიქსირეთ

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

232/8 დიაპაზონი წყაროზე მორგებული multicast-ისთვისაა დათმობილი და მოდელი აღწერილია RFC 4607-ში. თუ თქვენი ჯგუფი ამ დიაპაზონის გარეთაა, მაშინ როცა ფიქრობთ, რომ SSM-ს უშვებთ, გაჩერდით და დაადასტურეთ, რას გულისხმობს განლაგება სინამდვილეში, რადგან მიმღების შეერთებაც და მარშრუტიზატორის გადაგზავნის გადაწყვეტილებაც დამოკიდებულია მოდელის თანმიმდევრულობაზე.

შეამოწმეთ, რომ მიმღები წყაროს შეუერთდა

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

შეამოწმეთ უკუ გზა, სანამ გვირაბს შეხედავთ

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

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

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

წაიკითხეთ ბირთვის multicast მდგომარეობა და არა კონფიგურაცია

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

გადაწყვიტეთ, როგორ ამრავლებს გვირაბი სინამდვილეში

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

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

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