Chromecast- en DLNA-ûntdekking giet nea troch in rûtearre VPN

De cast-knop lit neat sjen, VLC DLNA bliuwt leech, en de masine oan de oare kant antwurdet op ping sûnder klachte. Dy kombinaasje is gjin breedbânprobleem en ek gjin firewall-riedsel. Ûntdekking yn dizze protokollen is in groepútwikseling op it lokale segmint, en in rûtearre tunnel ferfiert gjin groepadressearre ferkear. De sesje dy't jo besykje te starten wurdt nea oanbean.

Berikberens is goed. Ûntdekking ûntbrekt.

De myte: de tunnel hat in ynstelling of mear kapasiteit nedich

De gewoane suggestjes binne peer-to-peer-ferkear ynskeakelje, de MTU ferheegje of it type tunnelapparaat feroarje. Gjin fan alle foeget in broadcast-domein ta. Multicast wurdt levere troch switches en troch de lokale netwurkstapel, en in punt-tot-punt TUN-interface hat gjin groepadres om te oerstreamen.

Ynstellingen feroarje kin de flater lûder meitsje. It kin gjin oankundiging ferskine litte dêr't it protokol der nea ien stjoerd hat.

Wat de ûntdekkingsútwikseling eins is

Trije patroanen dekke hast alles wat jo tsjinkomme. mDNS stjoert nei 224.0.0.251 oer UDP 5353, SSDP stjoert nei 239.255.255.250 oer UDP 1900, en âldere SMB-browslist listen giene nei it broadcast-adres fan it subnet. Elk is adressearre oan in groep ynstee fan oan in host, en elk ferwachtet in harker op itselde segmint. In ûntfanger oan de oare kant fan in rûtearre tunnel is net op dat segmint, dus der komt neat oan.

Sels in trochstjoerde oankundiging draacht in nutslast: meastentiids it LAN-adres en de poarte fan de ôfstjoerder, dêr't de fjirde taskôger dan by komme moat.

Lês in opname foardat jo de tunnel feroarje

Meitsje in opname op 'e tunnelinterface wylst de app skant. In lege opname betsjuttet dat de oankundiging nea de grins oerstutsen hat, en gjin some tunnelôfstelling feroaret dat. Pakketten dy't wol ferskine wylst de app noch neat toant, betsjutte meastentiids dat it oankundige adres net berikber is fan 'e taskôger, wat in routingprobleem yn in ûntdekkingskostúm is.

Twa minuten opname ferfangt in oere fan rieden oer poarten: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Trije oplossings, de bêste koop earst

Wys de klant direkt nei it tsjinstadres. Foar DLNA, SMB en gewoane mediatsjinners slacht dat ûntdekking folslein oer en bewissiget it dat it nutslastpaad wurket, wat it de bêste earste test makket en tagelyk in brûkbere omgong. Chromecast is de útsûndering, om't de ûntfanger ferwachtet fûn te wurden ynstee fan adressearre.

Stjoer it protokol troch by de gateway. In mDNS-reflektor werhellet oankundigings tusken de tunnel en it LAN, en Avahi levert in reflektorseksje dy't in eksplisite ynterfaceslist nimt. Hâld de trochstjoering smel, en befêstigje dat it oankundige adres fan beide kanten berikber is, oars wiist it antwurd noch altyd nei in subnet dêr't de taskôger net nei rûtearje kin.

Brige ynstee fan rûtearje. In TAP-segmint wêr't de tsjinner it tap-apparaat op it LAN brigt, set beide einen yn ien broadcast-domein, sadat oankundigings sûnder feroaring oergean. It is ek de djoerste opsje, want ien subnet betsjuttet ien fal-domein en elke multicast-tsjinst op it LAN berikt no elke peer.

Wat net helpt, hoe faak it ek foarsteld wurdt

Om dev tun nei dev tap te skeakeljen sûnder in brêge lit in TAP-apparaat efter dat noch rûtearre wurdt, dus it gedrach feroaret net. client-to-client tastiet peer-to-peer-unicast en oerstreamt gjin broadcasts. In ûntdekkingspoarte nei ien host trochstjoere leveret gjin groepadressearre ferkear. In mediatsjinner bûn oan ien adres bliuwt op dat adres antwurdzje oant syn eigen konfiguraasje de VPN-interface neamt.

Test ien direkte unicast-fersyk, dan ien oankundige fersyk. As it earste wurket en it twadde net, is de tunnel sûn en is ûntdekking it hiele probleem.