Chromecast ve DLNA keşfi yönlendirilmiş bir VPN'i asla geçmez

Yayın düğmesi hiçbir şey listelemiyor, VLC DLNA boş kalıyor ve diğer uçtaki makine şikâyet etmeden ping'e yanıt veriyor. Bu kombinasyon bir bant genişliği sorunu değil ve güvenlik duvarı bilmecesi de değil. Bu protokollerde keşif, yerel segmentte bir grup alışverişidir ve yönlendirilmiş bir tünel grup adresli trafiği taşımaz. Başlatmaya çalıştığınız oturum asla sunulmaz.

Erişilebilirlik sorunsuz. Eksik olan keşif.

Efsane: tünelin bir ayara veya daha fazla kapasiteye ihtiyacı var

Olağan öneriler eşler arası trafiği etkinleştirmek, MTU'yu yükseltmek veya tünel aygıt türünü değiştirmektir. Hiçbiri bir yayın alanı eklemez. Multicast, anahtarlar ve yerel ağ yığını tarafından teslim edilir ve noktadan noktaya TUN arayüzünün taşıracağı bir grup adresi yoktur.

Ayarları değiştirmek hatayı daha gürültülü yapabilir. Ancak protokolün hiç göndermediği bir duyuruyu orada belirgin hale getiremez.

Keşif alışverişi gerçekte nedir

Karşılaşacağınız neredeyse her şeyi üç desen kapsar. mDNS UDP 5353 üzerinden 224.0.0.251 adresine gönderir, SSDP UDP 1900 üzerinden 239.255.255.250 adresine gönderir ve eski SMB tarama listeleri alt ağın yayın adresine giderdi. Her biri bir ana bilgisayara değil bir gruba adreslenir ve her biri aynı segmentte bir dinleyici bekler. Yönlendirilmiş bir tünelin ötesindeki alıcı o segmentte değildir, bu yüzden hiçbir şey ulaşmaz.

Aktarılan bir duyuru bile bir yük taşır: genellikle gönderenin LAN adresi ve bağlantı noktası, uzak izleyicinin bunlara ulaşabilmesi gerekir.

Tüneli değiştirmeden önce bir yakalama okuyun

Uygulama tararken tünel arayüzünde yakalama yapın. Boş bir yakalama, duyurunun sınırı hiç aşmadığı anlamına gelir ve hiçbir tünel ayarı bunu değiştirmez. Uygulama hâlâ hiçbir şey göstermezken yine de görünen paketler genellikle duyurulan adrese izleyiciden ulaşılamadığı anlamına gelir; bu, keşif kılığına girmiş bir yönlendirme sorunudur.

İki dakikalık yakalama, bağlantı noktaları hakkında bir saatlik tahminin yerini alır: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Üç çözüm, en ucuzu önce

İstemciyi doğrudan hizmet adresine yönlendirin. DLNA, SMB ve basit medya sunucuları için bu, keşfi tamamen atlar ve yük yolunun çalıştığını kanıtlar; bu da onu hem en iyi ilk test hem de kullanılabilir bir geçici çözüm yapar. Chromecast istisnadır, çünkü alıcı adreslenmekten çok bulunmayı bekler.

Protokolü ağ geçidinde aktarın. Bir mDNS yansıtıcısı duyuruları tünel ile LAN arasında yineler ve Avahi, açık bir arayüz listesi alan bir yansıtıcı bölümüyle gelir. Aktarımı dar tutun ve duyurulan adresin iki taraftan da erişilebilir olduğunu doğrulayın, yoksa yanıt hâlâ izleyicinin yönlendiremediği bir alt ağa işaret eder.

Yönlendirmek yerine köprü kurun. Sunucunun tap aygıtını LAN'a köprülediği bir TAP segmenti iki ucu tek bir yayın alanına koyar, böylece duyurular değişmeden geçer. Aynı zamanda en pahalı seçenektir, çünkü tek bir alt ağ tek bir arıza alanı demektir ve LAN'daki her multicast hizmeti artık her eşe ulaşır.

Ne işe yaramaz, ne kadar sık önerilirse önerilsin

Köprü olmadan dev tun yerine dev tap geçişi hâlâ yönlendirilen bir TAP aygıtı bırakır, bu yüzden davranış değişmez. client-to-client eşler arası unicast'a izin verir ve yayınları taşırmaz. Bir keşif bağlantı noktasını tek bir ana makineye iletmek grup adresli trafiği teslim etmez. Tek bir adrese bağlı bir medya sunucusu, kendi yapılandırması VPN arayüzünü listeleyene kadar o adreste yanıt vermeye devam eder.

Bir doğrudan unicast isteği, ardından bir duyurulmuş istek deneyin. Birincisi çalışıp ikincisi çalışmıyorsa tünel sağlıklıdır ve sorunun tamamı keşiftir.