Malkovro de Chromecast kaj DLNA neniam transiras vojigitan VPN
Elsendo kaj DLNA-retumado bezonas grupan interŝanĝon en la loka segmento, kaj vojigita tunelo neniam portas ĝin. Kontrolu la anoncon antaŭ la tunelo.
La elsenda butono listigas nenion, VLC DLNA restas malplena, kaj la maŝino ĉe la alia fino respondas al ping sen plendo. Tiu kombinaĵo ne estas bendlarĝa problemo nek enigmo de fajroŝirmilo. Malkovro en ĉi tiuj protokoloj estas grupa interŝanĝo en la loka segmento, kaj vojigita tunelo ne portas trafikon adresitan al grupo. La sesio, kiun vi provas komenci, neniam estas ofertita.
Atingebleco estas en ordo. Malkovro mankas.
La mito: la tunelo bezonas agordon aŭ pli da kapacito
La kutimaj sugestoj estas ebligi samrangan trafikon, altigi la MTU, aŭ ŝanĝi la tipon de la tunela aparato. Neniu el ili aldonas dissendan domajnon. Multicast estas liverata de ŝaltiloj kaj de la loka reta stako, kaj punkto-al-punkta TUN-interfaco havas neniun grupan adreson por inundigi.
Ŝanĝi agordojn povas igi la malsukceson pli laŭta. Ĝi ne povas igi anoncon aperi tie, kie la protokolo neniam sendis unu.
Kio vere estas la malkovra interŝanĝo
Tri ŝablonoj kovras preskaŭ ĉion, kion vi renkontos. mDNS sendas al 224.0.0.251 per UDP 5353, SSDP sendas al 239.255.255.250 per UDP 1900, kaj pli malnovaj SMB-retumaj listoj iris al la dissenda adreso de la subreto. Ĉiu estas adresita al grupo anstataŭ al gastiganto, kaj ĉiu atendas aŭskultanton en la sama segmento. Ricevanto trans vojigita tunelo ne estas en tiu segmento, do nenio alvenas.
Eĉ plusendita anonco portas utilan ŝarĝon: kutime la LAN-adreson kaj pordon de la sendinto, kiujn la fora spektanto poste devas povi atingi.
Legu kaptaĵon antaŭ ol ŝanĝi la tunelon
Kaptu ĉe la tunela interfaco dum la aplikaĵo skanas. Malplena kaptaĵo signifas, ke la anonco neniam transiris la limon, kaj neniu agordado de la tunelo tion ŝanĝas. Paketoj, kiuj tamen aperas dum la aplikaĵo ankoraŭ montras nenion, kutime signifas, ke la anoncita adreso ne estas atingebla de la spektanto — tio estas vojiga problemo en malkovra kostumo.
Du minutoj da kaptado anstataŭas horon da divenado pri pordoj: tcpdump -ni tun0 udp port 5353 or udp port 1900.
Tri riparoj, la plej malmultekosta unue
Direktu la klienton rekte al la adreso de la servo. Por DLNA, SMB kaj simplaj amaskomunikilaj serviloj tio tute preterlasas malkovron kaj pruvas, ke la utila vojo funkcias, kio igas ĝin la plej bona unua testado kaj ankaŭ uzebla flankvojo. Chromecast estas la escepto, ĉar la ricevanto atendas esti trovita anstataŭ adresita.
Plusendu la protokolon ĉe la enirejo. mDNS-reflektspegulo ripetas anoncojn inter la tunelo kaj la LAN, kaj Avahi liveras sekcion de reflektspegulo, kiu prenas eksplicitan liston de interfacoj. Tenu la plusendadon mallarĝa, kaj konfirmu, ke la anoncita adreso estas atingebla de ambaŭ flankoj, alie la respondo ankoraŭ montras al subreto, al kiu la spektanto ne povas vojigi.
Pontu anstataŭ vojigi. TAP-segmento, kie la servilo pontas la tap-aparaton al la LAN, metu ambaŭ finojn en unu dissendan domajnon, do anoncoj transiras senŝanĝe. Ĝi ankaŭ estas la plej multekosta opcio, ĉar unu subreto signifas unu fiaskan domajnon kaj ĉiu multicast-servo en la LAN nun atingas ĉiun samtavolanon.
Kio ne helpas, kiom ajn ofte oni proponas ĝin
Ŝanĝi dev tun al dev tap sen ponto lasas TAP-aparaton, kiu ankoraŭ estas vojigata, do la konduto ne ŝanĝiĝas. client-to-client permesas samrangan unicast kaj ne inundigas dissendojn. Plusendi malkovran pordon al unu gastiganto ne liveras trafikon adresitan al grupo. Amaskomunikila servilo ligita al unu adreso daŭre respondas ĉe tiu adreso, ĝis ĝia propra agordo listigos la VPN-interfacon.
Testu unu rektan unicast-peton, poste unu anoncitan peton. Se la unua funkcias kaj la dua ne, la tunelo estas sana kaj malkovro estas la tuta problemo.