La transmissió s'atura amb una VPN: descoberta, control o flux?
Un receptor absent, una sessió rebutjada i un flux que s'encalla fallen en llocs diferents. Anomeneu l'etapa abans de canviar la política de VPN del telèfon o la xarxa.
La transmissió es trenca en tres llocs que des del sofà semblen idèntics. Potser el telèfon no arriba a veure mai el receptor, potser el receptor apareix i després rebutja la sessió, o potser la sessió comença i s'encalla un minut més tard. Un túnel al telèfon canvia cadascun d'aquests camins de manera diferent, i en un d'ells no canvia res de res. Anomeneu primer l'etapa que falla i després decidiu si canviar la política és fins i tot la palanca correcta.
Anomeneu l'etapa que falla abans de canviar la política
Mireu què fa el telèfon just després de tocar la icona de transmissió. Una llista buida és un resultat de descoberta, un toc que informa d'un error és un resultat de control, i una sessió que comença abans d'encallar-se és un resultat de reproducció. Aquests tres tenen propietaris diferents, i normalment només els dos primers impliquen la configuració del túnel del telèfon.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Anoteu l'etapa abans de canviar res. Una correcció aplicada a l'etapa equivocada fa que la prova següent sigui il·legible, i la major part de la llegenda sobre la transmissió ve exactament d'aquesta confusió.
La descoberta és trànsit local, i un túnel l'amaga
Els receptors s'anuncien amb anuncis locals i el telèfon els troba amb consultes al mateix enllaç, així que qualsevol cosa que tregui el telèfon d'aquest enllaç treu el receptor de la llista. Un túnel que encamina tot el trànsit fora de la LAN pot amagar aquests intercanvis, i un permís de xarxa local a nivell d'aplicació els pot bloquejar fins i tot quan la ruta existeix. Un Wi-Fi de convidats amb aïllament de clients produeix la mateixa llista buida sense cap VPN. Demostreu que els dos dispositius comparteixen segment abans de culpar el túnel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRLa primera ordre llista què s'anuncia al segment de la màquina auxiliar, i la segona pregunta directament al grup de DNS multicast. Un receptor absent dels dos no apareixerà tampoc en una aplicació del telèfon, sigui quin sigui l'estat del túnel. Si el receptor és visible des d'un dispositiu amb el túnel desactivat i invisible des d'un amb el túnel activat, heu trobat l'etapa i la causa alhora.
Una excepció de LAN manté el túnel actiu
Molts clients ofereixen una excepció de xarxa local que deixa el túnel actiu mentre permet adreces locals. Feu servir aquesta configuració documentada en lloc de desactivar el kill switch o tot el tallafoc, perquè aquests canvien molt més del que la transmissió necessita. Si la xarxa separa els dispositius intel·ligents a propòsit, demaneu al propietari el trànsit concret de descoberta, control i retorn en lloc d'un accés pla.
nc -vz 192.168.1.50 8009Una prova de control contra el receptor separa el permís de l'abastabilitat: un port que respon vol dir que el camí existeix, mentre que un rebuig vol dir que es va permetre al telèfon descobrir el dispositiu i tot i així no hi pot parlar. Els ports 8008 i 8009 són els ports habituals de transmissió, i una aplicació pot fer servir d'altres, així que tracteu un sol port rebutjat com un indici i no com un veredicte. L'excepció i el permís de l'aplicació són independents, perquè concedir accés local no crea una ruta i afegir una ruta no concedeix permís. Un kill switch també pot deixar caure el trànsit local després d'una reconnexió, i per això la descoberta s'ha de tornar a provar quan el túnel torna.
La reproducció pot no fer servir la connexió del telèfon
En una sessió dirigida per l'aplicació, el telèfon dona al receptor una adreça de mitjans i el receptor la baixa per la seva pròpia connexió, així que canviar l'adreça pública del telèfon no fa res pel flux. Un títol limitat per compte encara pot fallar per motius propis, i els requisits de transmissió de Google cobreixen la compatibilitat d'aplicació i dispositiu, no el camí de xarxa. Encaminar el televisor mateix per un túnel és una configuració separada amb les seves pròpies qüestions de política.
Dos indicis distingeixen els modes. Una transmissió que sobreviu al bloqueig de la pantalla del telèfon és dirigida per l'aplicació, perquè el receptor baixa pel seu compte; una rèplica que s'atura quan es bloqueja la pantalla de l'emissor és un flux continu des del telèfon. Quan la descoberta i el control funcionen però la reproducció s'encalla, mireu en canvi l'enllaç Wi-Fi del receptor i el seu camí a internet, perquè una prova de velocitat al telèfon descriu el telèfon i no el televisor.
Desfeu l'excepció i torneu a provar
Tot canvi temporal necessita un camí de tornada, i l'ordre importa. Traieu l'excepció de LAN, torneu a connectar el túnel perquè el client reapliqui la seva política, després repetiu el pas de descoberta i anoteu si el receptor torna a desaparèixer. Aquesta seqüència us diu si l'excepció feia la feina o si alguna altra cosa va canviar entremig.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'Verifiqueu després les tres etapes per separat, perquè superar-ne una no diu res de les altres. Després comproveu que les aplicacions del telèfon no relacionades segueixen la ruta prevista, perquè una excepció local que s'ha convertit en silenci en un bypass complet és un resultat pitjor que una transmissió que necessita un toc extra.