Nid yw darganfod Chromecast a DLNA byth yn croesi VPN a lwybrwyd

Nid yw'r botwm bwrw yn rhestru dim, mae VLC DLNA yn aros yn wag, ac mae'r peiriant ar y pen arall yn ateb ping heb gwyn. Nid yw'r cyfuniad hwnnw yn broblem band eang nac yn ddirgelwch mur tân. Mae darganfod yn y protocolau hyn yn gyfnewid grŵp ar y segment lleol, ac nid yw twnnel llwybr yn cario traffig sydd â chyfeiriad grŵp. Ni chynigir y sesiwn rydych yn ceisio ei dechrau byth.

Mae cyrhaeddiad yn iawn. Mae darganfod ar goll.

Y myth: mae'r twnnel angen gosodiad neu fwy o gapasiti

Y cynigion arferol yw galluogi traffig peer-to-peer, codi'r MTU, neu newid math dyfais y twnnel. Nid oes yr un ohonynt yn ychwanegu parth darlledu. Mae multicast yn cael ei ddanfon gan switshis a chan y pentwr rhwydwaith lleol, ac nid oes gan ryngwyneb TUN pwynt-i-bwynt unrhyw gyfeiriad grŵp i'w lifo.

Gall newid gosodiadau wneud y methiant yn uwch. Ni all wneud i gyhoeddiad ymddangos lle na anfonodd y protocol un erioed.

Beth yw'r gyfnewid darganfod mewn gwirionedd

Mae tri phatrwm yn cwmpasu bron popeth y byddwch yn dod ar ei draws. Mae mDNS yn anfon i 224.0.0.251 ar UDP 5353, mae SSDP yn anfon i 239.255.255.250 ar UDP 1900, ac roedd rhestrau pori SMB hŷn yn mynd i gyfeiriad darlledu'r is-rwydwaith. Mae pob un wedi'i gyfeirio at grŵp yn hytrach nag at westeiwr, ac mae pob un yn disgwyl gwrandäwr ar yr un segment. Nid yw derbynnydd ar draws twnnel llwybr ar y segment hwnnw, felly nid oes dim yn cyrraedd.

Mae hyd yn oed cyhoeddiad sy'n cael ei ailgyfeirio yn cario llwyth: fel arfer cyfeiriad LAN a phorth yr anfonwr, y mae'n rhaid i'r gwyliwr pell allu eu cyrraedd wedyn.

Darllenwch gipiad cyn newid y twnnel

Cipiwch ar y rhyngwyneb twnnel tra bydd yr ap yn sganio. Mae cipiad gwag yn golygu na chroesodd y cyhoeddiad y ffin erioed, ac nid oes unrhyw faint o diwnio twnnel yn newid hynny. Mae pecynnau sy'n ymddangos tra nad yw'r ap yn dangos dim yn awgrymu fel arfer nad yw'r cyfeiriad a hysbysebir yn gyrraeddadwy o'r gwyliwr, sef problem llwybro mewn gwisg darganfod.

Mae dwy funud o gipio yn cymryd lle awr o ddyfalu am borthladdoedd: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tri thrwsiad, y rhataf yn gyntaf

Pwyntiwch y cleient yn uniongyrchol at gyfeiriad y gwasanaeth. Ar gyfer DLNA, SMB a gweinyddion cyfryngau syml mae hyn yn hepgor darganfod yn gyfan gwbl ac yn profi bod llwybr y llwyth yn gweithio, sy'n ei wneud y prawf cyntaf gorau yn ogystal â chyfaddawd defnyddiadwy. Chromecast yw'r eithriad, oherwydd mae'r derbynnydd yn disgwyl cael ei ddarganfod yn hytrach na'i gyfeirio.

Ailgyfeiriwch y protocol yn y giât. Mae adlewyrchydd mDNS yn ailadrodd cyhoeddiadau rhwng y twnnel a'r LAN, ac mae Avahi yn cynnwys adran adlewyrchydd sy'n cymryd rhestr ryngwyneb benodol. Cadwch yr ailgyfeirio yn gul, a chadarnhewch fod y cyfeiriad a hysbysebir yn gyrraeddadwy o'r ddwy ochr, neu mae'r ateb yn dal i bwyntio at is-rwydwaith na all y gwyliwr lwybro iddi.

Pontiwch yn lle llwybro. Mae segment TAP gyda'r gweinydd yn pontio'r ddyfais tap i'r LAN yn rhoi'r ddau ben mewn un parth darlledu, felly mae cyhoeddiadau yn croesi'n ddigyfnewid. Dyma hefyd yr opsiwn drutaf, oherwydd mae un is-rwydwaith yn golygu un parth methiant ac mae pob gwasanaeth multicast ar y LAN nawr yn cyrraedd pob cymar.

Beth nad yw'n helpu, waeth pa mor aml y'i cynigir

Mae newid dev tun i dev tap heb bont yn gadael dyfais TAP sy'n dal i gael ei llwybro, felly nid yw'r ymddygiad yn newid. client-to-client yn caniatáu unicast rhwng cymheiriaid ac nid yw'n llifo darllediadau. Nid yw anfon porthladd darganfod at un westeiwr yn danfon traffig sydd â chyfeiriad grŵp. Mae gweinydd cyfryngau wedi'i rwymo i un cyfeiriad yn parhau i ateb ar y cyfeiriad hwnnw nes bod ei ffurfweddiad ei hun yn rhestru'r rhyngwyneb VPN.

Profwch un cais unicast uniongyrchol, yna un cais a gyhoeddwyd. Os yw'r cyntaf yn gweithio a'r ail ddim, mae'r twnnel yn iach a darganfod yw'r broblem gyfan.