Chromecast ja DLNA avastus ei ületa kunagi marsruuditud VPN-i

Edastusnupp ei loetle midagi, VLC DLNA jääb tühjaks ja teises otsas olev masin vastab pingile ilma kaebusteta. See kombinatsioon ei ole ribalaiuse probleem ega tulemüüri mõistatus. Avastus nendes protokollides on grupivahetus kohalikus segmendis ja marsruuditud tunnel ei kanna grupiaadressiga liiklust. Sessioon, mida proovite käivitada, ei pakuta kunagi.

Kättesaadavus on korras. Avastus puudub.

Müüt: tunnel vajab seadet või rohkem mahtu

Tavapärased soovitused on lubada võrdväärse liiklus, tõsta MTU-d või muuta tunneli seadme tüüpi. Ükski neist ei lisa ringhäälingu domeeni. Multicast-edastuse teevad lülitid ja kohalik võrgupinu ning punkt-punktile TUN-liidesel ei ole ühtki grupiadressi, mida üle ujutada.

Seadete muutmine võib rikke valjemaks teha. See ei saa panna teatet ilmuma sinna, kuhu protokoll seda kunagi saatnud ei ole.

Mis on avastusvahetus tegelikult

Kolm mustrit katavad peaaegu kõik, mida kohtate. mDNS saadab aadressile 224.0.0.251 UDP 5353 kaudu, SSDP saadab aadressile 239.255.255.250 UDP 1900 kaudu ja vanemad SMB-sirvimisnimekirjad läksid alamvõrgu ringhäälinguaadressile. Igaüks on adresseeritud grupile, mitte hostile, ja igaüks ootab kuulajat samas segmendis. Marsruuditud tunneli taga olev vastuvõtja ei ole selles segmendis, seega ei saabu midagi.

Isegi edasiantud teade kannab kasulikku koormust: tavaliselt saatja LAN-aadress ja port, millele kaugvaataja peab siis juurde pääsema.

Lugege jäädvustust enne tunneli muutmist

Jäädvustage tunneli liidesel, kui rakendus skaneerib. Tühi jäädvustus tähendab, et teade ei ületanud kunagi piiri, ja ükski tunneli häälestus ei muuda seda. Paketid, mis siiski ilmuvad, kui rakendus ikka veel midagi ei näita, tähendavad tavaliselt, et reklaamitud aadress ei ole vaatajale kättesaadav — see on marsruutimisprobleem avastuskostüümis.

Kaks minutit jäädvustust asendab tunni portide kohta oletamist: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Kolm parandust, odavaim esimesena

Suunake klient otse teenuse aadressile. DLNA, SMB ja lihtsate meediaserverite puhul jätab see avastuse täielikult vahele ja tõestab, et kasuliku koormuse tee töötab, mis teeb sellest nii parima esimese testi kui ka kasutatava möödasõidu. Chromecast on erand, sest vastuvõtja ootab, et ta leitakse, mitte ei adresseerita.

Edastage protokoll lüüsil. mDNS-peegeldi kordab teateid tunneli ja LAN-i vahel ning Avahi pakub peegeldi jaotist, mis võtab selgesõnalise liideste loendi. Hoidke edastus kitsas ja kinnitage, et reklaamitud aadress on mõlemalt poolt kättesaadav, muidu osutab vastus endiselt alamvõrgule, kuhu vaataja ei saa marsruutida.

Sildage marsruutimise asemel. TAP-segment, kus server sildab tap-seadme LAN-i, paneb mõlemad otsad ühte ringhäälingu domeeni, nii et teated lähevad muutumatult läbi. See on ka kõige kallim valik, sest üks alamvõrk tähendab üht tõrkedomeeni ja iga multicast-teenus LAN-is jõuab nüüd iga võrdväärseni.

Mis ei aita, ükskõik kui sageli seda soovitatakse

Vahetamine dev tun vastu dev tap ilma sillata jätab TAP-seadme, mis on endiselt marsruuditud, seega käitumine ei muutu. client-to-client lubab võrdväärset unicast-liiklust ega ujuta ringhäälingut üle. Avastusporti ühele hostile edasi suunata ei anna grupiaadressiga liiklust. Ühele aadressile seotud meediaserver vastab jätkuvalt sellel aadressil, kuni selle enda konfiguratsioon loetleb VPN-liidese.

Testige üht otsest unicast-päringut, seejärel üht teatatud päringut. Kui esimene töötab ja teine mitte, on tunnel terve ja avastus on kogu probleem.