Chromecast пен DLNA анықтауы маршрутталған VPN-нен ешқашан өтпейді

Трансляция түймесі ештеңе тізімдемейді, VLC DLNA бос қалады, ал екінші жақтағы машина шағымсыз ping-ге жауап береді. Бұл үйлесім өткізу қабілетінің мәселесі де емес, firewall жұмбағы да емес. Бұл протоколдардағы анықтау — жергілікті сегменттегі топтық алмасу, және маршрутталған туннель топтық мекенжайлы трафикті тасымалдамайды. Сіз бастағыңыз келген сеанс ешқашан ұсынылмайды.

Қолжетімділік дұрыс. Анықтау жетіспейді.

Аңыз: туннельге параметр немесе көбірек сыйымдылық керек

Әдеттегі ұсыныстар — peer-to-peer трафигін қосу, MTU-ды көтеру немесе туннель құрылғысының түрін өзгерту. Олардың ешқайсысы трансляция доменін қоспайды. Multicast-ты коммутаторлар мен жергілікті желілік стек жеткізеді, ал нүкте-нүкте TUN интерфейсінде толтыратын топтық мекенжай жоқ.

Параметрлерді өзгерту сәтсіздікті одан әрі қатты ете алады. Бірақ протокол ешқашан жібермеген хабарламаны ол пайда ете алмайды.

Анықтау алмасуы шын мәнінде не

Үш үлгі кездесетін нәрсенің барлығын дерлік қамтиды. mDNS 224.0.0.251-ге UDP 5353 арқылы жібереді, SSDP 239.255.255.250-ге UDP 1900 арқылы жібереді, ал ескі SMB шолу тізімдері ішкі желінің трансляция мекенжайына баратын. Әрқайсысы хостқа емес, топқа арналған, және әрқайсысы сол сегменттегі тыңдаушыны күтеді. Маршрутталған туннельдің арғы жағындағы қабылдағыш сол сегментте емес, сондықтан ештеңе жетпейді.

Тіпті қайта жіберілген хабарлама пайдалы жүктемені тасиды: әдетте жіберушінің LAN мекенжайы мен порты, оған қашықтағы көрермен кейін жете алуы керек.

Туннельді өзгерту алдында жазбаны оқыңыз

Қолданба сканерлеп жатқанда туннель интерфейсінде жазба жасаңыз. Бос жазба хабарламаның шекарадан ешқашан өтпегенін білдіреді, және туннельдің ешқандай реттеуі оны өзгертпейді. Қолданба әлі ештеңе көрсетпесе де пайда болатын пакеттер әдетте жарияланған мекенжайдың көрермен үшін қолжетімсіз екенін білдіреді — бұл анықтау киімін киген маршруттау мәселесі.

Екі минуттық жазба порттар туралы бір сағаттық болжамды алмастырады: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Үш шешім, ең арзаны бірінші

Клиентті тікелей қызмет мекенжайына бағыттаңыз. DLNA, SMB және қарапайым медиа серверлер үшін бұл анықтауды толығымен айналып өтеді және пайдалы жүктеме жолының жұмыс істейтінін дәлелдейді, бұл оны ең жақсы бірінші сынақ әрі пайдалануға жарамды айналма жол етеді. Chromecast — ерекшелік, өйткені қабылдағыш мекенжайлануды емес, табылуды күтеді.

Протоколды шлюзде қайта жіберіңіз. mDNS шағылыстырғышы хабарламаларды туннель мен LAN арасында қайталайды, ал Avahi айқын интерфейстер тізімін алатын шағылыстырғыш бөлімін ұсынады. Қайта жіберуді тар ұстаңыз және жарияланған мекенжайдың екі жақтан да қолжетімді екенін растаңыз, әйтпесе жауап әлі де көрермен маршруттай алмайтын ішкі желіге нұсқайды.

Маршруттаудың орнына көпір жасаңыз. Сервер tap құрылғысын LAN-ға көпірлейтін TAP сегменті екі ұшты бір трансляция доменіне қояды, сондықтан хабарламалар өзгеріссіз өтеді. Бұл ең қымбат нұсқа да, өйткені бір ішкі желі бір ақау доменін білдіреді және LAN-дағы әрбір multicast қызметі енді әрбір әріптеске жетеді.

Не көмектеспейді, қанша жиі ұсынылса да

Көпірсіз dev tun-ді dev tap-ке ауыстыру әлі де маршрутталған TAP құрылғысын қалдырады, сондықтан мінез-құлық өзгермейді. client-to-client peer-to-peer unicast-қа рұқсат береді және трансляцияны толтырмайды. Анықтау портын бір хостқа бағыттау топтық мекенжайлы трафикті жеткізбейді. Бір мекенжайға байланған медиа сервер өз конфигурациясы VPN интерфейсін тізімдемейінше сол мекенжайда жауап бере береді.

Бір тікелей unicast сұранысын, содан кейін бір жарияланған сұранысты сынап көріңіз. Егер біріншісі жұмыс істеп, екіншісі істемесе, туннель сау және анықтау — бүкіл мәселе.