Chromecast un DLNA atklāšana nekad nešķērso maršrutētu VPN

Raides poga neko nerāda, VLC DLNA paliek tukšs, un mašīna otrā galā atbild uz ping bez sūdzībām. Šī kombinācija nav joslas platuma problēma un ne ugunsmūra mīkla. Atklāšana šajos protokolos ir grupu apmaiņa vietējā segmentā, un maršrutēts tunelis nenes grupu adresētu satiksmi. Sesija, kuru mēģināt sākt, nekad netiek piedāvāta.

Sasniedzamība ir kārtībā. Trūkst atklāšanas.

Mīts: tunelim vajag iestatījumu vai vairāk jaudas

Parastie ieteikumi ir iespējot vienādranga satiksmi, paaugstināt MTU vai mainīt tuneļa ierīces tipu. Neviens no tiem nepievieno apraides domēnu. Multicast piegādā komutatori un vietējā tīkla steka, un punktu-punkta TUN saskarnei nav grupas adreses, ko pārpludināt.

Iestatījumu maiņa var padarīt kļūmi skaļāku. Tā nevar likt paziņojumam parādīties tur, kur protokols to nekad nav sūtījis.

Kas īsti ir atklāšanas apmaiņa

Trīs modeļi aptver gandrīz visu, ar ko saskarsities. mDNS sūta uz 224.0.0.251 pa UDP 5353, SSDP sūta uz 239.255.255.250 pa UDP 1900, un vecāki SMB pārlūkošanas saraksti gāja uz apakštīkla apraides adresi. Katrs ir adresēts grupai, nevis saimniekdatoram, un katrs gaida klausītāju tajā pašā segmentā. Uztvērējs aiz maršrutēta tuneļa nav šajā segmentā, tāpēc nekas nenonāk.

Pat tālāknosūtīts paziņojums nes lietderīgo slodzi: parasti sūtītāja LAN adresi un portu, kuriem tālvadības skatītājam pēc tam jāspēj piekļūt.

Izlasiet ierakstu pirms tuneļa maiņas

Ierakstiet tuneļa saskarnē, kamēr lietotne skenē. Tukšs ieraksts nozīmē, ka paziņojums nekad nav šķērsojis robežu, un nekāda tuneļa regulēšana to nemaina. Paketes, kas tomēr parādās, kamēr lietotne joprojām neko nerāda, parasti nozīmē, ka paziņotā adrese skatītājam nav sasniedzama — tā ir maršrutēšanas problēma atklāšanas kostīmā.

Divas minūtes ieraksta aizstāj stundu minējumu par portiem: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Trīs risinājumi, lētākais pirmais

Novirziet klientu tieši uz pakalpojuma adresi. DLNA, SMB un vienkāršiem mediju serveriem tas pilnībā izlaiž atklāšanu un pierāda, ka lietderīgās slodzes ceļš darbojas, kas to padara par labāko pirmo testu un arī izmantojamu apvedceļu. Chromecast ir izņēmums, jo uztvērējs gaida, ka to atradīs, nevis adresēs.

Pārsūtiet protokolu pie vārtejas. mDNS atstarotājs atkārto paziņojumus starp tuneli un LAN, un Avahi piegādā atstarotāja sadaļu, kas pieņem skaidru saskarņu sarakstu. Turiet pārsūtīšanu šauru un apstipriniet, ka paziņotā adrese ir sasniedzama no abām pusēm, citādi atbilde joprojām norāda uz apakštīklu, uz kuru skatītājs nevar maršrutēt.

Tiltu, nevis maršrutējiet. TAP segments, kurā serveris tiltā savieno tap ierīci ar LAN, ievieto abus galus vienā apraides domēnā, tāpēc paziņojumi pāriet nemainīti. Šī ir arī dārgākā iespēja, jo viens apakštīkls nozīmē vienu atteices domēnu un katrs LAN multicast pakalpojums tagad sasniedz katru vienādrangi.

Kas nepalīdz, lai cik bieži to ieteiktu

Pārslēgšana no dev tun uz dev tap bez tilta atstāj TAP ierīci, kas joprojām tiek maršrutēta, tāpēc uzvedība nemainās. client-to-client pieļauj vienādranga unicast un nepārpludina apraides. Atklāšanas porta pārsūtīšana uz vienu saimniekdatoru nepiegādā grupu adresētu satiksmi. Mediju serveris, kas piesaistīts vienai adresei, turpina atbildēt šajā adresē, līdz tā paša konfigurācija uzskaita VPN saskarni.

Izmēģiniet vienu tiešu unicast pieprasījumu, pēc tam vienu paziņotu pieprasījumu. Ja pirmais darbojas un otrais ne, tunelis ir vesels un atklāšana ir visa problēma.