Cast pysähtyy VPN:llä: löytäminen, ohjaus vai suoratoisto?

Cast katkeaa kolmessa kohdassa, jotka näyttävät sohvalta samanlaisilta. Puhelin ei ehkä koskaan näe vastaanotinta, vastaanotin voi ilmestyä ja sitten hylätä istunnon, tai istunto voi alkaa ja jumittua minuuttia myöhemmin. Puhelimen tunneli muuttaa kutakin näistä poluista eri tavalla, ja yhden kohdalla se ei muuta mitään. Nimeä ensin epäonnistuva vaihe ja päätä vasta sitten, onko käytännön muuttaminen edes oikea vipu.

Nimeä epäonnistuva vaihe ennen käytännön muuttamista

Katso, mitä puhelin tekee heti cast-kuvakkeen napauttamisen jälkeen. Tyhjä lista on löytämisen tulos, virheen ilmoittava napautus on ohjauksen tulos ja ennen jumittumista alkava istunto on toiston tulos. Näillä kolmella on eri omistajat, ja yleensä vain kaksi ensimmäistä liittyvät puhelimen tunneliasetuksiin.

Kirjoita vaihe muistiin ennen kuin muutat mitään. Väärään vaiheeseen sovellettu korjaus tekee seuraavasta testistä lukukelvottoman, ja suurin osa cast-tarinoista syntyy juuri tästä sekaannuksesta.

Löytäminen on paikallista liikennettä, ja tunneli kätkee sen

Vastaanottimet ilmoittautuvat paikallisilla tiedotteilla ja puhelin löytää ne saman linkin kyselyillä, joten kaikki, mikä poistaa puhelimen siltä linkiltä, poistaa vastaanottimen listalta. Tunneli, joka ohjaa kaiken liikenteen pois lähiverkosta, voi kätkeä ne vaihdot, ja sovellustason lähiverkkolupa voi estää ne, vaikka reitti olisi olemassa. Asiakaseristyksen sisältävä vieras-Wi-Fi tuottaa saman tyhjän listan ilman VPN:ää. Todista, että kaksi laitetta jakavat segmentin, ennen kuin syytät tunnelia.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Ensimmäinen komento listaa, mikä ilmoittautuu apukoneen segmentissä, ja toinen kysyy suoraan multicast DNS -ryhmältä. Vastaanotin, joka puuttuu molemmista, ei ilmesty puhelinsovellukseenkaan, olipa puhelimen tunnelin tila mikä tahansa. Jos vastaanotin näkyy laitteesta, jonka tunneli on pois päältä, ja on näkymätön laitteesta, jonka tunneli on päällä, löysit vaiheen ja syyn yhdessä.

LAN-poikkeus pitää tunnelin päällä

Monet asiakkaat tarjoavat lähiverkkopoikkeuksen, joka pitää tunnelin aktiivisena ja sallii paikalliset osoitteet. Käytä sitä dokumentoitua asetusta sen sijaan, että kytkisit pois kill switchin tai koko palomuurin, koska ne muuttavat paljon enemmän kuin cast tarvitsee. Jos verkko erottaa älylaitteet tarkoituksella, pyydä omistajalta tarkka löytämis-, ohjaus- ja paluuliikenne tasaisen pääsyn sijaan.

nc -vz 192.168.1.50 8009

Vastaanotinta vasten tehtävä ohjaustesti erottaa luvan tavoitettavuudesta: vastaava portti tarkoittaa, että polku on olemassa, kun taas hylkäys tarkoittaa, että puhelimen sallittiin löytää laite eikä se silti voi puhua sille. Portit 8008 ja 8009 ovat tavalliset cast-portit, ja sovellus voi käyttää muita, joten pidä yhtä hylättyä porttia vihjeenä äläkä tuomiona. Poikkeus ja sovelluslupa pysyvät erillisinä, koska paikallinen pääsy ei luo reittiä eikä reitin lisääminen anna lupaa. Kill switch voi myös pudottaa paikallisen liikenteen uudelleenyhdistämisen jälkeen, minkä vuoksi löytäminen on testattava uudelleen heti, kun tunneli palaa.

Toisto ei ehkä käytä puhelimen yhteyttä

Sovelluksen ohjaamassa istunnossa puhelin antaa vastaanottimelle mediaosoitteen ja vastaanotin lataa sen oman yhteytensä kautta, joten puhelimen julkisen osoitteen muuttaminen ei tee suoratoistolle mitään. Tiliin sidottu nimike voi silti epäonnistua omista syistään, ja Googlen cast-vaatimukset kattavat sovelluksen ja laitteen yhteensopivuuden, eivät verkkopolkua. Television itsensä ohjaaminen tunnelin läpi on erillinen kokoonpano, jolla on omat käytäntökysymyksensä.

Kaksi vihjettä erottaa tilat. Cast, joka kestää puhelimen näytön lukitsemisen, on sovelluksen ohjaama, koska vastaanotin lataa itse; peilaus, joka pysähtyy, kun lähettäjän näyttö lukittuu, on puhelimesta tuleva jatkuva suoratoisto. Kun löytäminen ja ohjaus onnistuvat mutta toisto jumittuu, katso sen sijaan vastaanottimen Wi-Fi-linkkiä ja sen internetpolkua, koska puhelimessa tehty nopeustesti kuvaa puhelinta eikä televisiota.

Peru poikkeus ja testaa uudelleen

Jokainen väliaikainen muutos tarvitsee paluutien, ja järjestyksellä on väliä. Poista LAN-poikkeus, yhdistä tunneli uudelleen, jotta asiakas soveltaa käytäntönsä uudelleen, toista sitten löytämisvaihe ja kirjaa, katoaako vastaanotin taas. Tämä järjestys kertoo, tekikö poikkeus työn vai muuttuiko välissä jotain muuta.

# 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'

Tarkista sen jälkeen kolme vaihetta erikseen, koska yhden onnistuminen ei kerro muista mitään. Tarkista sitten, että muut puhelinsovellukset seuraavat edelleen aiottua reittiä, koska paikallinen poikkeus, joka muuttui hiljaa täydelliseksi ohitukseksi, on huonompi tulos kuin cast, joka vaatii yhden ylimääräisen napautuksen.