Chromecast-ისა და DLNA-ის აღმოჩენა არასოდეს კვეთს მარშრუტიზებულ VPN-ს

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

წვდომადობა რიგზეა. აღმოჩენა აკლია.

მითი: გვირაბს პარამეტრი ან მეტი ტევადობა სჭირდება

ჩვეულებრივი შემოთავაზებებია peer-to-peer ტრაფიკის ჩართვა, MTU-ის აწევა ან გვირაბის მოწყობილობის ტიპის შეცვლა. არც ერთი მათგანი არ ამატებს მაუწყებლობის დომენს. Multicast-ს აწვდიან კომუტატორები და ლოკალური ქსელის სტეკი, და წერტილ-წერტილ TUN ინტერფეისს არ აქვს ჯგუფური მისამართი, რომ გადაიჭრას.

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

რა არის სინამდვილეში აღმოჩენის გაცვლა

სამი ნიმუში ფარავს თითქმის ყველაფერს, რაც შეგხვდებათ. mDNS აგზავნის 224.0.0.251-ზე UDP 5353-ით, SSDP აგზავნის 239.255.255.250-ზე UDP 1900-ით, და ძველი SMB დათვალიერების სიები მიდიოდა ქვექსელის მაუწყებლობის მისამართზე. თითოეული მიმართულია ჯგუფზე და არა ჰოსტზე, და თითოეული ელოდება მსმენელს იმავე სეგმენტში. მიმღები მარშრუტიზებული გვირაბის მეორე მხარეს არ არის ამ სეგმენტში, ამიტომ არაფერი არ აღწევს.

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

წაიკითხეთ ჩანაწერი გვირაბის შეცვლამდე

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

ორი წუთის ჩანაწერი ცვლის პორტებზე ერთი საათის ვარაუდს: tcpdump -ni tun0 udp port 5353 or udp port 1900.

სამი გამოსავალი, ყველაზე იაფი პირველი

მიუთითეთ კლიენტი პირდაპირ სერვისის მისამართზე. DLNA-სთვის, SMB-სთვის და ჩვეულებრივი მედიასერვერებისთვის ეს მთლიანად გამოტოვებს აღმოჩენას და ამტკიცებს, რომ დატვირთვის გზა მუშაობს, რაც მას ხდის როგორც საუკეთესო პირველ ტესტად, ისე გამოსადეგ შემოვლით გზად. Chromecast გამონაკლისია, რადგან მიმღები ელოდება, რომ იპოვიან და არა მიმართავენ.

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

ააგეთ ხიდი მარშრუტიზაციის ნაცვლად. TAP სეგმენტი, სადაც სერვერი tap მოწყობილობას LAN-ზე ახიდებს, ორივე ბოლოს ერთ მაუწყებლობის დომენში აყენებს, ამიტომ განცხადებები უცვლელად გადადის. ეს ასევე ყველაზე ძვირი ვარიანტია, რადგან ერთი ქვექსელი ნიშნავს ერთ უკმარისობის დომენს და LAN-ის ყოველი multicast სერვისი ახლა ყველა თანატოლს აღწევს.

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

გადართვა dev tun-დან dev tap-ზე ხიდის გარეშე ტოვებს TAP მოწყობილობას, რომელიც კვლავ მარშრუტიზებულია, ამიტომ ქცევა არ იცვლება. client-to-client ნებას რთავს თანატოლთა შორის unicast-ს და არ ტბორავს მაუწყებლობას. აღმოჩენის პორტის ერთ ჰოსტზე გადატანა არ აწვდის ჯგუფურ მისამართზე მიმართულ ტრაფიკს. ერთ მისამართზე მიბმული მედიასერვერი აგრძელებს ამ მისამართზე პასუხს, სანამ მისი კონფიგურაცია VPN ინტერფეისს ჩამოთვლის.

სცადეთ ერთი პირდაპირი unicast მოთხოვნა, შემდეგ ერთი გამოცხადებული მოთხოვნა. თუ პირველი მუშაობს და მეორე არა, გვირაბი ჯანსაღია და აღმოჩენა მთელი პრობლემაა.