Chromecast eta DLNAren aurkikuntzak ez du inoiz bideratutako VPN bat zeharkatzen

Igotze-botoiak ez du ezer zerrendatzen, VLC DLNA hutsik geratzen da, eta beste muturreko makinak ping-ari erantzuten dio kexarik gabe. Konbinazio hori ez da banda-zabalerako arazoa ez eta suebakiko misterioa ere. Protokolo hauetan aurkikuntza segmentu lokalean egiten den talde-trukea da, eta bideratutako tunel batek ez du talde-helbideratutako trafikoa eramaten. Hasi nahi duzun saioa ez da inoiz eskaintzen.

Irisgarritasuna ondo dago. Aurkikuntza falta da.

Mitoa: tunelak ezarpen bat edo gaitasun handiagoa behar du

Ohiko iradokizunak parekoen arteko trafikoa gaitzea, MTU igotzea edo tunelaren gailu mota aldatzea dira. Horietako batek ere ez du difusio-domeinu bat gehitzen. Multicast kommutadoreek eta sare lokalaren pilak ematen dute, eta puntutik punturako TUN interfazeak ez du gainezka egiteko talde-helbiderik.

Ezarpenak aldatzeak hutsegitea ozenago egin dezake. Ezin du iragarki bat protokoloak inoiz bidali ez zuen tokian agerrarazi.

Zer da benetan aurkikuntza-trukea

Hiru ereduk ia topatuko duzun guztia hartzen dute. mDNSk 224.0.0.251ra bidaltzen du UDP 5353 bidez, SSDPk 239.255.255.250ra bidaltzen du UDP 1900 bidez, eta SMB arakatze-zerrenda zaharrak azpisarearen difusio-helbidera joaten ziren. Bakoitza talde bati zuzentzen zaio, ez ostalari bati, eta bakoitzak entzule bat espero du segmentu berean. Bideratutako tunel baten beste aldeko hargailua ez dago segmentu horretan, beraz ez da ezer iristen.

Errepikatutako iragarkiak ere karga erabilgarria darama: normalean bidaltzailearen LAN helbidea eta portua, urruneko ikusleak gero iritsi behar dituenak.

Irakurri harrapaketa bat tunela aldatu aurretik

Harrapatu tunelaren interfazean aplikazioa eskaneatzen ari den bitartean. Harrapaketa hutsak esan nahi du iragarkiak ez zuela inoiz muga zeharkatu, eta tunelaren doikuntza orok ez du hori aldatzen. Aplikazioak oraindik ezer erakusten ez duen bitartean agertzen diren paketeek normalean esan nahi dute iragarritako helbidea ez dela iristeko modukoa ikuslearentzat, hau da, aurkikuntzaren jantzia duen bideratze-arazoa.

Bi minutuko harrapaketak ordubeteko portuei buruzko asmakizunak ordezkatzen ditu: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Hiru konponbide, merkeena lehenengo

Zuzendu bezeroa zerbitzuaren helbidera zuzenean. DLNA, SMB eta media-zerbitzari arruntetarako horrek aurkikuntza guztiz saltatzen du eta karga-bidea funtzionatzen duela frogatzen du, eta horrek lehen proba onena ez ezik erabilgarria den behin-behineko irtenbidea ere egiten du. Chromecast da salbuespena, hargailuak aurkitua izan nahi baitu, ez helbideratua.

Errepikatu protokoloa atean. mDNS islatzaile batek iragarkiak tunelaren eta LANaren artean errepikatzen ditu, eta Avahi-k islatzaile atal bat dakar interfaze-zerrenda esplizitua hartzen duena. Eutsi errepikapena estu, eta egiaztatu iragarritako helbidea bi aldetatik iristeko modukoa dela, bestela erantzunak oraindik ikusleak bideratu ezin duen azpisare batera seinalatzen du.

Zubiratu bideratu beharrean. Zerbitzariak tap gailua LANera zubiratzen duen TAP segmentu batek bi muturrak difusio-domeinu bakarrean jartzen ditu, beraz iragarkiak aldaketarik gabe igarotzen dira. Aukera garestiena ere bada, azpisare batek hutsegite-domeinu bat esan nahi baitu eta LANeko multicast zerbitzu bakoitzak pare bakoitzera iristen baita orain.

Zerk ez duen laguntzen, zenbat aldiz iradoki ere

Zubirik gabe dev tunetik dev tapera aldatzeak TAP gailu bideratua uzten du, beraz portaera ez da aldatzen. client-to-client parekoen arteko unicast-a baimentzen du eta ez du difusioa gainezka egiten. Aurkikuntza-portu bat ostalari bakarrera birbidaltzeak ez du talde-helbideratutako trafikorik eramaten. Helbide bakarrari lotutako media-zerbitzari batek helbide horretan erantzuten jarraitzen du bere konfigurazioak VPN interfazea zerrendatu arte.

Probatu unicast eskaera zuzen bat, gero iragarritako eskaera bat. Lehenak funtzionatzen badu eta bigarrenak ez, tunela osasuntsu dago eta aurkikuntza da arazo osoa.