A Chromecast- és DLNA-felderítés soha nem kel át egy routolt VPN-en

A cast gomb semmit nem listáz, a VLC DLNA üres marad, és a másik végén lévő gép panasz nélkül válaszol a pingre. Ez a kombináció nem sávszélesség-probléma és nem tűzfalrejtély. A felderítés ezekben a protokollokban csoportos csere a helyi szegmensen, és egy routolt alagút nem szállít csoportcímzett forgalmat. A munkamenet, amelyet indítani próbál, soha nem ajánlódik fel.

Az elérhetőség rendben van. A felderítés hiányzik.

A mítosz: az alagútnak beállítás vagy több kapacitás kell

A szokásos javaslatok a peer-to-peer forgalom engedélyezése, az MTU növelése vagy az alagút eszköztípusának módosítása. Egyik sem ad hozzá broadcast tartományt. A multicastot a kapcsolók és a helyi hálózati verem szállítja, és egy pont-pont TUN interfésznek nincs csoportcíme, amit eláraszthatna.

A beállítások módosítása hangosabbá teheti a hibát. Nem tudja elérni, hogy egy bejelentés ott jelenjen meg, ahová a protokoll soha nem küldött egyet.

Mi is valójában a felderítési csere

Három minta lefedi szinte mindent, amivel találkozik. Az mDNS a 224.0.0.251-re küld UDP 5353-on, az SSDP a 239.255.255.250-re küld UDP 1900-on, a régebbi SMB-böngészőlisták pedig az alhálózat broadcast címére mentek. Mindegyik csoportnak szól, nem hosztnak, és mindegyik ugyanazon a szegmensen vár egy hallgatót. A routolt alagút túloldalán lévő vevő nincs ezen a szegmensen, ezért semmi nem érkezik meg.

Még egy továbbított bejelentés is hordoz hasznos terhet: általában a küldő LAN-címét és portját, amelyeket a távoli nézőnek aztán el kell érnie.

Olvasson egy rögzítést, mielőtt módosítja az alagutat

Rögzítsen az alagút interfészén, miközben az alkalmazás szkennel. Az üres rögzítés azt jelenti, hogy a bejelentés soha nem lépte át a határt, és az alagút semmilyen hangolása nem változtat ezen. A csomagok, amelyek mégis megjelennek, miközben az alkalmazás továbbra sem mutat semmit, általában azt jelentik, hogy a hirdetett cím nem érhető el a néző felől – ez felderítésnek álcázott útválasztási probléma.

Két perc rögzítés helyettesít egy óra találgatást a portokról: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Három megoldás, a legolcsóbb elsőként

Irányítsa a klienst közvetlenül a szolgáltatás címére. A DLNA, az SMB és az egyszerű médiaszerverek esetében ez teljesen kihagyja a felderítést, és bizonyítja, hogy a hasznos teher útvonala működik, ami a legjobb első tesztté és egyben használható kerülőúttá teszi. A Chromecast a kivétel, mert a vevő azt várja, hogy megtalálják, nem pedig hogy címezzenek rá.

Továbbítsa a protokollt az átjárón. Az mDNS-reflektor megismétli a bejelentéseket az alagút és a LAN között, az Avahi pedig olyan reflektor-szakaszt szállít, amely kifejezett interfészlistát vesz át. Tartsa szűken a továbbítást, és erősítse meg, hogy a hirdetett cím mindkét oldalról elérhető, különben a válasz továbbra is olyan alhálózatra mutat, ahová a néző nem tud routolni.

Hidaljon át routolás helyett. Egy TAP-szegmens, ahol a szerver a tap eszközt a LAN-ra hidalja, mindkét véget egy broadcast tartományba helyezi, így a bejelentések változatlanul átjutnak. Ez a legdrágább lehetőség is, mert egy alhálózat egy hiba tartományt jelent, és a LAN minden multicast szolgáltatása most minden peerhez eljut.

Mi nem segít, bármilyen gyakran javasolják is

A dev tun dev tap-ra váltása híd nélkül TAP-eszközt hagy, amely továbbra is routolt, tehát a viselkedés nem változik. client-to-client peer-to-peer unicastot engedélyez, és nem árasztja el a broadcastot. Egy felderítési port egyetlen hosztra továbbítása nem szállít csoportcímzett forgalmat. Egy címhez kötött médiaszerver továbbra is azon a címen válaszol, amíg a saját konfigurációja fel nem sorolja a VPN interfészt.

Teszteljen egy közvetlen unicast kérést, majd egy bejelentett kérést. Ha az első működik és a második nem, az alagút egészséges, és a felderítés a teljes probléma.