Descoperirea Chromecast și DLNA nu traversează niciodată un VPN rutat

Butonul de transmitere nu afișează nimic, VLC DLNA rămâne gol, iar mașina de la celălalt capăt răspunde la ping fără să se plângă. Această combinație nu este o problemă de lățime de bandă și nici o enigmă a paravanului de foc. Descoperirea în aceste protocoale este un schimb de grup în segmentul local, și un tunel rutat nu transportă trafic adresat către grup. Sesiunea pe care încercați să o porniți nu este niciodată oferită.

Accesibilitatea este în regulă. Lipsește descoperirea.

Mitul: tunelul are nevoie de o setare sau de mai multă capacitate

Sugestiile obișnuite sunt să activați traficul peer-to-peer, să ridicați MTU sau să schimbați tipul dispozitivului tunelului. Niciuna nu adaugă un domeniu de difuzare. Multicast este livrat de comutatoare și de stiva de rețea locală, iar o interfață TUN punct-la-punct nu are nicio adresă de grup pe care să o inunde.

Schimbarea setărilor poate face defecțiunea mai zgomotoasă. Nu poate face un anunț să apară acolo unde protocolul nu a trimis niciodată unul.

Ce este de fapt schimbul de descoperire

Trei tipare acoperă aproape tot ce veți întâlni. mDNS trimite către 224.0.0.251 pe UDP 5353, SSDP trimite către 239.255.255.250 pe UDP 1900, iar vechile liste de navigare SMB mergeau la adresa de difuzare a subrețelei. Fiecare este adresată unui grup și nu unei gazde, și fiecare așteaptă un ascultător în același segment. Un receptor de cealaltă parte a unui tunel rutat nu este în acel segment, așa că nu ajunge nimic.

Chiar și un anunț retransmis poartă o încărcătură utilă: de obicei adresa LAN și portul expeditorului, pe care spectatorul îndepărtat trebuie apoi să le poată atinge.

Citiți o captură înainte de a schimba tunelul

Capturați pe interfața tunelului în timp ce aplicația scanează. O captură goală înseamnă că anunțul nu a trecut niciodată granița, iar nicio reglare a tunelului nu schimbă asta. Pachetele care apar totuși în timp ce aplicația încă nu arată nimic înseamnă de obicei că adresa anunțată nu este accesibilă de la spectator, ceea ce este o problemă de rutare deghizată în descoperire.

Două minute de captură înlocuiesc o oră de presupuneri despre porturi: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Trei soluții, cea mai ieftină prima

Îndreptați clientul direct către adresa serviciului. Pentru DLNA, SMB și servere media simple, aceasta sare complet peste descoperire și dovedește că traseul încărcăturii funcționează, ceea ce îl face cel mai bun prim test și totodată o soluție de ocol utilizabilă. Chromecast este excepția, pentru că receptorul așteaptă să fie găsit, nu adresat.

Retransmiteți protocolul la gateway. Un reflector mDNS repetă anunțurile între tunel și LAN, iar Avahi vine cu o secțiune de reflector care acceptă o listă explicită de interfețe. Țineți retransmisia îngustă și confirmați că adresa anunțată este accesibilă din ambele părți, altfel răspunsul indică în continuare o subrețea către care spectatorul nu poate ruta.

Puneți un pod în loc să rutați. Un segment TAP în care serverul puntează dispozitivul tap în LAN aduce ambele capete în același domeniu de difuzare, așa că anunțurile trec neschimbate. Este și cea mai scumpă opțiune, pentru că o singură subrețea înseamnă un singur domeniu de defecțiune și fiecare serviciu multicast din LAN ajunge acum la fiecare egal.

Ce nu ajută, oricât de des ar fi sugerat

Trecerea de la dev tun la dev tap fără un pod lasă un dispozitiv TAP care este încă rutat, așa că comportamentul nu se schimbă. client-to-client permite unicast între egali și nu inundă difuzările. Redirecționarea unui port de descoperire către o singură gazdă nu livrează trafic adresat către grup. Un server media legat de o singură adresă continuă să răspundă pe acea adresă până când propria configurație menționează interfața VPN.

Testați o cerere unicast directă, apoi o cerere anunțată. Dacă prima funcționează și a doua nu, tunelul este sănătos și descoperirea este întreaga problemă.