La transmissió funcionava abans d’activar la VPN del router i falla immediatament després, mentre la navegació normal al telèfon continua funcionant. Els dos fets són coherents, perquè la transmissió no és una sola connexió. El telèfon descobreix i controla el receptor per la xarxa local, i després el receptor descarrega els mitjans per la seva pròpia connexió.

Dos camins que fallen de manera diferent

El camí de control és local. Un telèfon troba un receptor preguntant a la xarxa local i després obre una connexió de control a l’adreça que ha après. Si el receptor no apareix mai a la llista, el pas de descobriment ha fallat abans que es demanés cap mitjà.

El camí dels mitjans no és necessàriament local. Molts receptors descarreguen ells mateixos el flux, per la seva pròpia connexió i amb les seves pròpies credencials, de manera que la ruta del telèfon no descriu la ruta del receptor. Un telèfon que sembla usar una sortida no diu res sobre on va el trànsit del televisor.

Aquesta separació és la raó per la qual la fallada sembla estranya. El túnel va canviar la taula d’encaminament del telèfon i no la del televisor, així que un símptoma que apareix en un costat de la parella s’ha de rastrejar en aquest costat. Rastrejar el dispositiu equivocat és la raó habitual que una solució sembli no fer res.

Per què falla primer el descobriment

El descobriment sol viatjar per multicast d’enllaç local. mDNS envia a 224.0.0.251 al port UDP 5353, i SSDP envia a 239.255.255.250 al port UDP 1900. Tots dos estan limitats a un enllaç per disseny, i per això un router no els reenvia entre segments sense l’ajuda d’un repetidor o d’un proxy. Una VPN encaminada no amplia un grup multicast, i una ruta de política no pot fer que un grup que mai ha sortit de l’enllaç aparegui en un altre.

Per tant, la primera fallada no té res a veure amb el xifratge. El multicast del telèfon surt de la interfície per on s’ha enviat, el receptor és en un segment que no el veu mai, i la llista de dispositius torna buida. Una llista buida no és prova que el televisor hagi perdut l’accés a internet.

L’aïllament produeix un símptoma idèntic sense cap VPN. Les xarxes de convidats i l’aïllament de clients als punts d’accés impedeixen deliberadament que els dispositius es parlin, i activar una VPN al router damunt d’un segment aïllat no canvia res d’això. Comproveu la configuració d’aïllament abans de comprovar el túnel. És la resposta més barata i la més habitual.

La disposició dels segments és l’altra meitat. Un segon router, un node mesh en un altre mode o un segment cablejat darrere d’un altre NAT col·loquen el receptor en un lloc on el trànsit de descobriment del telèfon no arriba.

Per què una política per defecte pot engolir una petició local

Un router que encamina tot el trànsit cap a un túnel instal·la una ruta per defecte a la interfície del túnel. Si el prefix de la LAN no queda exclòs d’aquesta política, un paquet adreçat a un dispositiu a dos metres ara coincideix amb la ruta per defecte, i el router envia la petició de control al túnel en lloc de al commutador.

StageWhat carries itHow a router VPN interferes
DiscoveryLink-local multicast on a single segmentNot extended across segments, and not repaired by a route
Control connectionUnicast to the receiver address on the LANA policy default can capture the LAN destination and tunnel it
Media fetchThe receiver's own connectionUnaffected by the phone's route, but affected by the TV's own policy
Account authorizationTokens held by the applicationCan fail for reasons unrelated to any route

L’ordre de les regles decideix el resultat. L’encaminament per política avalua les regles per ordre de prioritat, així que una excepció per al prefix local ha d’aparèixer abans de la regla que selecciona la taula del túnel. Afegir l’excepció després de la regla del túnel no té cap efecte, i per això una configuració que sembla correcta encara pot enviar el trànsit de la LAN a una sortida remota.

La reparació és estreta: permeteu les destinacions locals concretes que necessita el flux de transmissió i deixeu la resta de l’aïllament tranquil. Treure l’aïllament de clients com a primer pas arregla el símptoma, però descarta un control que la xarxa havia de tenir.

Una consulta ràpida al telèfon aclareix quina de les dues fallades teniu. Si la ruta cap al receptor apunta al túnel, el problema és la política. Si apunta a la LAN i el descobriment continua fallant, el problema és el multicast o l’aïllament, i cap canvi de ruta no ajudarà.

ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcp

Proveu el pas que ha canviat, no el país

Les observacions registrades valen més que els experiments repetits. Anoteu si el receptor apareix a la llista de dispositius, si una petició de control hi arriba i si la reproducció comença quan es tria un flux. Cada resposta treu un pas de sospita.

Després proveu cada pas directament en lloc de canviar de sortida. Canviar de país de VPN prova el camí dels mitjans i deixa els passos de descobriment i control intactes, així que pot semblar que ajuda per casualitat sense ensenyar-vos res.

Pel costat del receptor, comproveu la seva pròpia ruta i l’estat del seu compte. Un televisor que descarrega els mitjans per una sortida diferent de la del telèfon és un disseny normal, i una fallada allà és una qüestió sobre la política de xarxa del receptor, no sobre el túnel del telèfon.

Escriviu el resultat en una sola frase sobre quin pas s’ha trencat i què l’ha canviat. Aquesta frase val més que una setmana de canviar de país, i sobreviu a la propera actualització de firmware.

La transmissió és un bon cas de prova per a una regla general sobre túnels. Quan se n’afegeix un a una xarxa, la primera pregunta és quines destinacions no hi haurien d’haver entrat mai. La segona és quines d’aquestes la política va acceptar igualment en silenci.

Articles relacionats