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 սեգմենտը, որտեղ սերվերը tap սարքը կամրջում է LAN-ին, երկու ծայրերը դնում է մեկ հեռարձակման տիրույթում, ուստի հայտարարություններն անցնում են անփոփոխ։ Սա նաև ամենաթանկ տարբերակն է, որովհետև մեկ ենթացանց նշանակում է մեկ ձախողման տիրույթ և LAN-ի յուրաքանչյուր multicast ծառայություն այժմ հասնում է յուրաքանչյուր հասակակցի։

Ինչ չի օգնում, որքան էլ հաճախ առաջարկվի

Անցումը dev tun-ից dev tap-ի՝ առանց կամրջի, թողնում է TAP սարք, որը դեռ երթուղված է, ուստի վարքը չի փոխվում։ client-to-client թույլատրում է հասակակիցների միջև unicast և չի ողողում հեռարձակումները։ Հայտնաբերման պորտը մեկ հոսթ փոխանցելը խմբային հասցեով երթևեկություն չի հասցնում։ Մեկ հասցեին կապված մեդիասերվերը շարունակում է պատասխանել այդ հասցեով, մինչև իր սեփական կարգավորումը նշի VPN ինտերֆեյսը։

Փորձարկեք մեկ ուղիղ unicast հարցում, ապա մեկ հայտարարված հարցում։ Եթե առաջինն աշխատում է, իսկ երկրորդը՝ ոչ, թունելը առողջ է, և հայտնաբերումը ողջ խնդիրն է։