Chromecastin ja DLNA:n löytäminen ei koskaan ylitä reititettyä VPN:ää

Lähetyspainike ei listaa mitään, VLC DLNA pysyy tyhjänä ja toisessa päässä oleva kone vastaa pingiin valittamatta. Yhdistelmä ei ole kaistanleveysongelma eikä palomuurin arvoitus. Löytäminen näissä protokollissa on ryhmävaihto paikallisessa segmentissä, ja reititetty tunneli ei kuljeta ryhmäosoitettua liikennettä. Istuntoa, jota yrität aloittaa, ei koskaan tarjota.

Tavoitettavuus on kunnossa. Löytäminen puuttuu.

Myytti: tunneli tarvitsee asetuksen tai lisää kapasiteettia

Tavalliset ehdotukset ovat vertaisverkkoliikenteen salliminen, MTU:n nostaminen tai tunnelilaitteen tyypin vaihtaminen. Mikään niistä ei lisää lähetysaluetta. Multicastin toimittavat kytkimet ja paikallinen verkkopino, eikä piste-piste-TUN-rajapinnalla ole yhtään ryhmäosoitetta tulvitettavaksi.

Asetusten vaihtaminen voi tehdä epäonnistumisesta äänekkäämmän. Se ei voi saada ilmoitusta ilmestymään sinne, minne protokolla ei koskaan lähettänyt sellaista.

Mitä löytämisvaihto oikeastaan on

Kolme mallia kattavat lähes kaiken, mitä kohtaat. mDNS lähettää osoitteeseen 224.0.0.251 UDP 5353:ssa, SSDP lähettää osoitteeseen 239.255.255.250 UDP 1900:ssa, ja vanhemmat SMB-selausluettelot menivät aliverkon lähetysosoitteeseen. Jokainen on osoitettu ryhmälle eikä isännälle, ja jokainen odottaa kuuntelijaa samassa segmentissä. Reititetyn tunnelin takana oleva vastaanottaja ei ole siinä segmentissä, joten mitään ei saavu.

Jopa välitetty ilmoitus kantaa hyötykuorman: yleensä lähettäjän LAN-osoite ja portti, joihin etäkatsojan on silloin päästävä.

Lue kaappaus ennen kuin muutat tunnelia

Kaappaa tunnelin rajapinnalla, kun sovellus skannaa. Tyhjä kaappaus tarkoittaa, että ilmoitus ei koskaan ylittänyt rajaa, eikä mikään tunnelin viritys muuta sitä. Paketit, joita silti ilmestyy, kun sovellus ei vielä näytä mitään, tarkoittavat yleensä, että ilmoitettu osoite ei ole katsojan tavoitettavissa – kyse on reititysongelmasta löytämisen asussa.

Kaksi minuuttia kaappausta korvaa tunnin porttien arvailun: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Kolme korjausta, halvin ensin

Osoita asiakas suoraan palvelun osoitteeseen. DLNA:n, SMB:n ja tavallisten mediaserverien kohdalla tämä ohittaa löytämisen kokonaan ja todistaa, että hyötykuorman polku toimii, mikä tekee siitä sekä parhaan ensimmäisen testin että käyttökelpoisen kiertotien. Chromecast on poikkeus, koska vastaanottaja odottaa tulevansa löydetyksi eikä osoitetuksi.

Välitä protokolla yhdyskäytävässä. mDNS-heijastin toistaa ilmoituksia tunnelin ja LAN:in välillä, ja Avahin mukana tulee heijastinosa, joka ottaa eksplisiittisen rajapintaluettelon. Pidä välitys kapeana ja varmista, että ilmoitettu osoite on tavoitettavissa molemmilta puolilta, muuten vastaus osoittaa yhä aliverkkoon, johon katsoja ei voi reitittää.

Sillitä reitittämisen sijaan. TAP-segmentti, jossa palvelin siltaa tap-laitteen LAN:iin, asettaa molemmat päät samaan lähetysalueeseen, joten ilmoitukset kulkevat muuttumattomina. Se on myös kallein vaihtoehto, koska yksi aliverkko tarkoittaa yhtä vikaantumisaluetta ja jokainen LAN:in multicast-palvelu tavoittaa nyt jokaisen vertaisen.

Mikä ei auta, kuinka usein sitä ehdotetaankin

Vaihto dev tun → dev tap ilman siltaa jättää TAP-laitteen, joka on yhä reititetty, joten käyttäytyminen ei muutu. client-to-client sallii vertaisten välisen unicastin eikä tulvita lähetyksiä. Löytämisportin edelleenlähetys yhdelle isännälle ei toimita ryhmäosoitettua liikennettä. Yhteen osoitteeseen sidottu mediaserveri vastaa edelleen siinä osoitteessa, kunnes sen oma kokoonpano luettelee VPN-rajapinnan.

Testaa yksi suora unicast-pyyntö ja sitten yksi ilmoitettu pyyntö. Jos ensimmäinen toimii ja toinen ei, tunneli on kunnossa ja löytäminen on koko ongelma.