რატომ წყვეტს კასტინგი მუშაობას როუტერის VPN-ის ჩართვის შემდეგ
აღმოჩენა link-local multicast-ზე მიდის, ხოლო ტელევიზორი მედიას თავად იწერს. პოლისის ნაგულისხმევ წესს შეუძლია LAN მოთხოვნა დაიჭიროს და გვირაბში გაგზავნოს.
კასტინგი მუშაობდა როუტერის VPN-ის ჩართვამდე და მაშინვე ფუჭდება ჩართვის შემდეგ, თუმცა ტელეფონზე ჩვეულებრივი დათვალიერება კვლავ მუშაობს. ეს ორი ფაქტი თავსებადია, რადგან კასტინგი ერთი კავშირი არ არის. ტელეფონი მიმღებს ლოკალურ ქსელში პოულობს და მართავს, შემდეგ კი მიმღები მედიას საკუთარი კავშირით იწერს.
ორი გზა, რომლებიც სხვადასხვანაირად ფუჭდება
მართვის გზა ლოკალურია. ტელეფონი მიმღებს ლოკალური ქსელის გამოკითხვით პოულობს, შემდეგ კი ნასწავლ მისამართზე მართვის კავშირს ხსნის. თუ მიმღები სიაში არასოდეს გამოჩნდა, აღმოჩენის ეტაპი მედიის მოთხოვნამდე ჩავარდა.
მედიის გზა სულაც არ არის აუცილებლად ლოკალური. ბევრი მიმღები ნაკადს თავად იწერს, საკუთარი კავშირითა და საკუთარი მონაცემებით, ამიტომ ტელეფონის მარშრუტი მიმღების მარშრუტს არ აღწერს. ტელეფონი, რომელიც თითქოს ერთი გასასვლელით სარგებლობს, ვერაფერს ამბობს იმაზე, სად მიდის ტელევიზორის ტრაფიკი.
ეს გაყოფაა მიზეზი, რატომ გამოიყურება ხარვეზი უცნაურად. გვირაბმა ტელეფონის მარშრუტიზაციის ცხრილი შეცვალა და ტელევიზორისა არ შეცვალა, ამიტომ წყვილის ერთ მხარეს გამოვლენილი სიმპტომი იმავე მხარეს უნდა მოძებნოთ. არასწორი მოწყობილობის კვლევა ჩვეულებრივი მიზეზია იმისა, რომ გამოსწორება თითქოს არაფერს აკეთებს.
რატომ ფუჭდება აღმოჩენა პირველად
აღმოჩენა ჩვეულებრივ link-local multicast-ზე მიდის. mDNS აგზავნის 224.0.0.251-ზე UDP პორტ 5353-ზე, ხოლო SSDP აგზავნის 239.255.255.250-ზე UDP პორტ 1900-ზე. ორივე კონსტრუქციით ერთ რგოლზეა შემოფარგლული, ამიტომ როუტერი მათ სეგმენტებს შორის გადამყვანის ან პროქსის დახმარების გარეშე არ გადასცემს. მარშრუტირებული VPN multicast ჯგუფს არ აფართოებს, ხოლო პოლისის მარშრუტს არ შეუძლია ჯგუფი, რომელიც რგოლიდან არასოდეს გასულა, სხვა რგოლზე გამოაჩინოს.
ამიტომ პირველ ხარვეზს დაშიფვრასთან საერთო არაფერი აქვს. ტელეფონის multicast ტოვებს ინტერფეისს, რომლიდანაც გაიგზავნა, მიმღები სეგმენტშია, რომელიც მას ვერ ხედავს, და მოწყობილობების სია ცარიელი ბრუნდება. ცარიელი სია არ არის მტკიცებულება, რომ ტელევიზორმა ინტერნეტზე წვდომა დაკარგა.
იზოლაცია იგივე სიმპტომს იძლევა VPN-ის გარეშეც. სტუმრის ქსელები და წვდომის წერტილის კლიენტების იზოლაცია განზრახ აჩერებს მოწყობილობებს ერთმანეთთან საუბარს, და იზოლირებულ სეგმენტზე როუტერის VPN-ის ჩართვა ამაში არაფერს ცვლის. გვირაბის შემოწმებამდე შეამოწმეთ იზოლაციის პარამეტრი. ეს უფრო იაფი პასუხია და უფრო ხშირი.
სეგმენტების განლაგება მეორე ნახევარია. მეორე როუტერი, სხვა რეჟიმში მყოფი mesh კვანძი ან სხვა NAT-ის უკან მყოფი სადენიანი სეგმენტი — ყველა მიმღებს ათავსებს იქ, სადაც ტელეფონის აღმოჩენის ტრაფიკი არ აღწევს.
რატომ შეიძლება პოლისის ნაგულისხმევმა წესმა ლოკალური მოთხოვნა ჩაყლაპოს
როუტერი, რომელიც მთელ ტრაფიკს გვირაბში ატარებს, გვირაბის ინტერფეისზე ნაგულისხმევ მარშრუტს აყენებს. თუ LAN პრეფიქსი ამ პოლისიდან არ არის გამორიცხული, ორ მეტრში მდგარ მოწყობილობაზე მისამართიანი პაკეტი ახლა ნაგულისხმევს ემთხვევა და როუტერი მართვის მოთხოვნას გვირაბში აგზავნის, სვიჩზე კი არა.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
წესების რიგი შედეგს წყვეტს. პოლისის მარშრუტიზაცია წესებს პრიორიტეტის მიხედვით აფასებს, ამიტომ ლოკალური პრეფიქსის გამონაკლისი უნდა იყოს იმ წესზე ადრე, რომელიც გვირაბის ცხრილს ირჩევს. გამონაკლისის გვირაბის წესის შემდეგ დამატება ეფექტს არ იძლევა, ამიტომ სწორად შემახედი კონფიგურაციაც კი შეიძლება LAN ტრაფიკი დისტანციურ გასასვლელში გაგზავნიდეს.
გამოსწორება ვიწროა: დაუშვით კონკრეტული ლოკალური დანიშნულებები, რომლებიც კასტინგის ნაკადს სჭირდება, და დანარჩენი იზოლაცია უცვლელად დატოვეთ. კლიენტების იზოლაციის მოშორება პირველ ნაბიჯად სიმპტომს კურნავს, მაგრამ ქსელის კონსტრუქციით გათვალისწინებულ კონტროლს ყრის.
ტელეფონზე სწრაფი შემოწმება გადაწყვეტს, რომელი ხარვეზი გაქვთ. თუ მიმღებისკენ მარშრუტი გვირაბზე მიუთითებს, პრობლემა პოლისშია. თუ LAN-ზე მიუთითებს და აღმოჩენა მაინც ფუჭდება, პრობლემა multicast ან იზოლაციაა და მარშრუტის შეცვლა ვერ დაეხმარება.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpშეამოწმეთ შეცვლილი ეტაპი და არა ქვეყანა
ჩაწერილი დაკვირვებები გამეორებულ ექსპერიმენტებს სჯობს. აღნიშნეთ, ჩნდება თუ არა მიმღები მოწყობილობების სიაში, აღწევს თუ არა მას მართვის მოთხოვნა და იწყება თუ არა დაკვრა ნაკადის არჩევის შემდეგ. ყოველი პასუხი ერთ ეტაპს აშორებს ეჭვს.
შემდეგ თითოეული ეტაპი პირდაპირ შეამოწმეთ და ნუ გადართავთ გასასვლელ ადგილებს. VPN ქვეყნის შეცვლა მედიის გზას ამოწმებს და აღმოჩენისა და მართვის ეტაპებს უცვლელად ტოვებს, ამიტომ შეიძლება შემთხვევით დაეხმაროს და არაფერი გასწავლოს.
მიმღების მხარეს შეამოწმეთ მისი საკუთარი მარშრუტი და ანგარიშის მდგომარეობა. ტელევიზორი, რომელიც მედიას ტელეფონისგან განსხვავებული გასასვლელით იწერს, ნორმალური კონსტრუქციაა, და იქ ხარვეზი მიმღების ქსელური პოლისის საკითხია და არა ტელეფონის გვირაბის.
შედეგი ჩაწერეთ ერთი წინადადებით იმის შესახებ, რომელი ეტაპი გატყდა და რამ შეცვალა ის. ეს წინადადება ერთი კვირის ქვეყნების შეცვლაზე მეტად ღირს და გადაურჩება შემდეგ firmware განახლებას.
კასტინგი კარგი საცდელი შემთხვევაა გვირაბების ზოგადი წესისთვის. როცა ქსელს გვირაბი ემატება, პირველი კითხვაა რომელი დანიშნულებები არასოდეს უნდა შესულიყო მასში, მეორე კი — რომელი მათგანი მიიღო პოლისმა მდუმარედ.