Zbulimi i Chromecast dhe DLNA nuk kalon kurrë një VPN të rrugëzuar

Butoni i transmetimit nuk liston asgjë, VLC DLNA mbetet bosh, dhe makina në skajin tjetër përgjigjet ndaj ping pa u ankuar. Ky kombinim nuk është problem i gjerësisë së brezit dhe as enigmë e murit të zjarrit. Zbulimi në këto protokolle është një shkëmbim grupi në segmentin lokal, dhe një tunel i rrugëzuar nuk çon trafik me adresë grupi. Sesioni që po përpiqeni të filloni nuk ofrohet kurrë.

Arritshmëria është në rregull. Mungon zbulimi.

Miti: tuneli kërkon një konfigurim ose më shumë kapacitet

Sugjerimet e zakonshme janë të aktivizoni trafikun mes palëve, të ngrini MTU-në ose të ndryshoni llojin e pajisjes së tunelit. Asnjëra prej tyre nuk shton një domen transmetimi. Multicast dorëzohet nga komutatorët dhe nga stiva e rrjetit lokal, dhe një ndërfaqe TUN pikë-për-pikë nuk ka asnjë adresë grupi për të përmbytur.

Ndryshimi i konfigurimeve mund ta bëjë dështimin më të zëshëm. Nuk mund të bëjë që një njoftim të shfaqet atje ku protokolli nuk ka dërguar kurrë një të tillë.

Çfarë është në të vërtetë shkëmbimi i zbulimit

Tre modele mbulojnë pothuajse gjithçka që do të takoni. mDNS dërgon në 224.0.0.251 përmes UDP 5353, SSDP dërgon në 239.255.255.250 përmes UDP 1900, dhe listat më të vjetra të shfletimit SMB shkonin në adresën e transmetimit të nënrrjetit. Secila i drejtohet një grupi dhe jo një hosti, dhe secila pret një dëgjues në të njëjtin segment. Marrësi përtej një tuneli të rrugëzuar nuk është në atë segment, prandaj asgjë nuk arrin.

Edhe një njoftim i përcjellë mbart një ngarkesë: zakonisht adresën LAN dhe portën e dërguesit, të cilave shikuesi i largët duhet pastaj të mund t'u arrijë.

Lexoni një regjistrim përpara se të ndryshoni tunelin

Regjistroni në ndërfaqen e tunelit ndërsa aplikacioni skanon. Një regjistrim bosh do të thotë që njoftimi nuk e ka kaluar kurrë kufirin, dhe asnjë rregullim i tunelit nuk e ndryshon këtë. Paketat që shfaqen megjithatë ndërsa aplikacioni ende nuk tregon asgjë zakonisht nënkuptojnë që adresa e njoftuar nuk arrihet nga shikuesi, gjë që është një problem rrugëzimi me kostum zbulimi.

Dy minuta regjistrim zëvendësojnë një orë hamendjeje për portat: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre zgjidhje, më e lira e para

Drejtojeni klientin direkt në adresën e shërbimit. Për DLNA, SMB dhe serverë media të thjeshtë kjo e kapërcen plotësisht zbulimin dhe provon që rruga e ngarkesës funksionon, gjë që e bën atë provën e parë më të mirë dhe një zgjidhje kalimtare të përdorshme. Chromecast është përjashtimi, sepse marrësi pret të gjendet dhe jo të adresohet.

Përcillni protokollin në portë. Një reflektues mDNS përsërit njoftimet mes tunelit dhe LAN-it, dhe Avahi vjen me një seksion reflektuesi që merr një listë të qartë ndërfaqesh. Mbajeni përcjelljen të ngushtë dhe konfirmoni që adresa e njoftuar arrihet nga të dyja anët, përndryshe përgjigja vazhdon të tregojë një nënrrjet ku shikuesi nuk mund të rrugëzojë.

Ndërtoni një urë në vend të rrugëzimit. Një segment TAP ku serveri urëzon pajisjen tap në LAN i vendos të dyja skajet në një domen transmetimi, kështu që njoftimet kalojnë të pandryshuara. Është gjithashtu opsioni më i shtrenjtë, sepse një nënrrjet do të thotë një domen dështimi dhe çdo shërbim multicast në LAN tani arrin çdo palë.

Çfarë nuk ndihmon, sado shpesh të sugjerohet

Kalimi nga dev tun në dev tap pa një urë lë një pajisje TAP që ende rrugëzohet, prandaj sjellja nuk ndryshon. client-to-client lejon unicast mes palëve dhe nuk përmbyt transmetimet. Përcjellja e një porte zbulimi në një host të vetëm nuk dorëzon trafik me adresë grupi. Një server media i lidhur me një adresë të vetme vazhdon të përgjigjet në atë adresë derisa konfigurimi i tij të listojë ndërfaqen VPN.

Provoni një kërkesë të drejtpërdrejtë unicast, pastaj një kërkesë të njoftuar. Nëse e para funksionon dhe e dyta jo, tuneli është i shëndoshë dhe zbulimi është i gjithë problemi.