Chromecast અને DLNA શોધ ક્યારેય રાઉટેડ VPN પાર કરતી નથી

કાસ્ટ બટન કંઈ યાદી બતાવતું નથી, VLC DLNA ખાલી રહે છે, અને બીજા છેડાનું મશીન ફરિયાદ વિના ping નો જવાબ આપે છે. આ સંયોજન બેન્ડવિડ્થની સમસ્યા નથી કે ફાયરવોલનું રહસ્ય પણ નથી. આ પ્રોટોકોલમાં શોધ એ સ્થાનિક સેગમેન્ટ પરનો જૂથ વિનિમય છે, અને રાઉટેડ ટનલ જૂથ-સરનામાંવાળું ટ્રાફિક વહન કરતી નથી. તમે શરૂ કરવા માગતું સત્ર ક્યારેય ઓફર થતું નથી.

પહોંચ ઠીક છે. શોધ ખૂટે છે.

દંતકથા: ટનલને સેટિંગ કે વધુ ક્ષમતાની જરૂર છે

સામાન્ય સૂચનો છે પીઅર-ટુ-પીઅર ટ્રાફિક સક્ષમ કરવો, MTU વધારવો, અથવા ટનલ ઉપકરણનો પ્રકાર બદલવો. એમાંથી કોઈ બ્રોડકાસ્ટ ડોમેન ઉમેરતું નથી. મલ્ટિકાસ્ટ સ્વિચ અને સ્થાનિક નેટવર્ક સ્ટેક દ્વારા પહોંચાડવામાં આવે છે, અને પોઈન્ટ-ટુ-પોઈન્ટ 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 પરની દરેક મલ્ટિકાસ્ટ સેવા હવે દરેક પીઅર સુધી પહોંચે છે.

શું મદદ કરતું નથી, ભલે ગમે તેટલી વાર સૂચવાય

બ્રિજ વિના dev tun માં dev tap બદલવાથી TAP ઉપકરણ રહી જાય છે જે હજી રાઉટેડ છે, તેથી વર્તન બદલાતું નથી. client-to-client પીઅર-ટુ-પીઅર યુનિકાસ્ટની મંજૂરી આપે છે અને બ્રોડકાસ્ટ પૂરતું નથી. શોધ પોર્ટને એક હોસ્ટ પર ફોરવર્ડ કરવાથી જૂથ-સરનામાંવાળું ટ્રાફિક પહોંચતું નથી. એક સરનામે બંધાયેલ મીડિયા સર્વર તેના પોતાના રૂપરેખાંકનમાં VPN ઇન્ટરફેસ સૂચિબદ્ધ ન થાય ત્યાં સુધી તે સરનામે જવાબ આપતું રહે છે.

એક સીધી યુનિકાસ્ટ વિનંતી અજમાવો, પછી એક જાહેર કરેલી વિનંતી. જો પહેલી કામ કરે અને બીજી નહીં, તો ટનલ સ્વસ્થ છે અને શોધ એ આખી સમસ્યા છે.