Chromecast ir DLNA aptikimas niekada neperžengia maršrutizuoto VPN
Transliavimas ir DLNA naršymas reikalauja grupinio maino vietiniame segmente, o maršrutizuotas tunelis jo niekada neperneša. Patikrinkite paskelbimą prieš tunelį.
Transliavimo mygtukas nieko nerodo, VLC DLNA lieka tuščias, o mašina kitame gale atsako į ping be priekaištų. Toks derinys nėra pralaidumo problema ir ne ugniasienės mįslė. Aptikimas šiuose protokoluose yra grupinis mainas vietiniame segmente, ir maršrutizuotas tunelis neperneša srauto su grupiniais adresais. Sesija, kurią bandote pradėti, niekada nesiūloma.
Pasiekiamumas tvarkingas. Trūksta aptikimo.
Mitas: tuneliui reikia nustatymo arba daugiau pralaidumo
Įprasti pasiūlymai yra įjungti lygiaverčių tinklų srautą, padidinti MTU arba pakeisti tunelio įrenginio tipą. Nė vienas jų neprideda transliacijos domeno. Multicast pristato komutatoriai ir vietinė tinklo krūva, o taškas-taškas TUN sąsaja neturi grupinio adreso, kurį būtų galima užtvindyti.
Nustatymų keitimas gali padaryti gedimą garsesnį. Jis negali priversti paskelbimo atsirasti ten, kur protokolas niekada jo nesiuntė.
Kas iš tikrųjų yra aptikimo mainas
Trys modeliai apima beveik viską, su kuo susidursite. mDNS siunčia į 224.0.0.251 per UDP 5353, SSDP siunčia į 239.255.255.250 per UDP 1900, o senesni SMB naršymo sąrašai ėjo į potinklio transliacijos adresą. Kiekvienas yra adresuotas grupei, o ne hostui, ir kiekvienas laukia klausytojo tame pačiame segmente. Gavėjas už maršrutizuoto tunelio nėra tame segmente, todėl niekas neatvyksta.
Net persiųstas paskelbimas neša naudingąją apkrovą: paprastai siuntėjo LAN adresą ir prievadą, kuriuos nuotolinis žiūrovas tada turi galėti pasiekti.
Perskaitykite įrašą prieš keisdami tunelį
Įrašykite tunelio sąsajoje, kol programa nuskaito. Tuščias įrašas reiškia, kad paskelbimas niekada neperžengė ribos, ir joks tunelio derinimas to nepakeis. Paketai, kurie vis dėlto pasirodo, kol programa vis dar nieko nerodo, paprastai reiškia, kad paskelbtas adresas yra nepasiekiamas žiūrovui — tai maršrutizavimo problema aptikimo kostiumu.
Dvi minutės įrašo pakeičia valandą spėlionių apie prievadus: tcpdump -ni tun0 udp port 5353 or udp port 1900.
Trys sprendimai, pigiausias pirmas
Nukreipkite klientą tiesiai į paslaugos adresą. DLNA, SMB ir paprastiems medijos serveriams tai visiškai praleidžia aptikimą ir įrodo, kad naudingosios apkrovos kelias veikia, todėl tai yra geriausias pirmasis bandymas ir naudotinas apėjimas. Chromecast yra išimtis, nes imtuvas tikisi būti rastas, o ne adresuotas.
Persiųskite protokolą prie vartų. mDNS atšvaitas kartoja paskelbimus tarp tunelio ir LAN, o Avahi pateikia atšvaito sekciją, kuri priima aiškų sąsajų sąrašą. Laikykite persiuntimą siaurą ir patvirtinkite, kad paskelbtas adresas pasiekiamas iš abiejų pusių, kitaip atsakymas vis dar rodo potinklį, į kurį žiūrovas negali maršrutizuoti.
Tiltą vietoj maršrutizavimo. TAP segmentas, kuriame serveris tiltu sujungia tap įrenginį su LAN, padeda abu galus į vieną transliacijos domeną, todėl paskelbimai praeina nepakitę. Tai taip pat brangiausias variantas, nes vienas potinklis reiškia vieną gedimo domeną ir kiekviena LAN multicast paslauga dabar pasiekia kiekvieną lygiavertį.
Kas nepadeda, kad ir kaip dažnai siūloma
Perjungimas dev tun į dev tap be tilto palieka TAP įrenginį, kuris vis dar maršrutizuojamas, todėl elgsena nesikeičia. client-to-client leidžia lygiaverčių unicast ir neužtvindo transliacijų. Aptikimo prievado persiuntimas vienam hostui nepristato srauto su grupiniais adresais. Medijos serveris, susietas su vienu adresu, toliau atsako tuo adresu, kol jo paties konfigūracija nurodys VPN sąsają.
Išbandykite vieną tiesioginę unicast užklausą, tada vieną paskelbtą užklausą. Jei pirmoji veikia, o antroji ne, tunelis sveikas ir aptikimas yra visa problema.