Cast stop op 'n VPN: ontdekking, beheer of stroom?
'n Ontbrekende ontvanger, 'n geweierde sessie en 'n stroom wat vasval, misluk op verskillende plekke. Benoem die fase voordat jy die foon se VPN-beleid of die netwerk verander.
Cast breek op drie plekke wat van die bank af dieselfde lyk. Die foon sien dalk nooit die ontvanger nie, die ontvanger verskyn dalk en weier dan die sessie, of die sessie begin en val 'n minuut later vas. 'n Tonnel op die foon verander elkeen van daardie bane anders, en vir een van hulle verander dit glad niks nie. Benoem eers die fase wat misluk en besluit dan of 'n beleidsverandering selfs die regte hefboom is om te trek.
Benoem die fase wat misluk voordat jy die beleid verander
Kyk wat die foon doen onmiddellik nadat jy op die cast-ikoon tik. 'n Leë lys is 'n ontdekkingsuitslag, 'n tik wat mislukking rapporteer is 'n beheervraag, en 'n sessie wat begin voordat dit vasval is 'n weergawe-uitslag. Daardie drie het verskillende eienaars, en net die eerste twee betrek gewoonlik die foon se tonnelinstellings.
| 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 |
Skryf die fase neer voordat jy enigiets verander. 'n Herstel wat op die verkeerde fase toegepas word, maak die volgende toets onleesbaar, en die meeste cast-oorlewering kom juis uit daardie verwarring.
Ontdekking is plaaslike verkeer, en 'n tonnel verberg dit
Ontvangers adverteer hulself deur plaaslike aankondigings en die foon vind hulle met navrae op dieselfde skakel, so enigiets wat die foon van daardie skakel verwyder, verwyder die ontvanger van die lys. 'n Tonnel wat alle verkeer weg van die LAN lei, kan daardie uitruilings verberg, en 'n programvlak-plaaslikenetwerktoestemming kan hulle blokkeer selfs wanneer die roete bestaan. Gaste-Wi-Fi met kliëntisolasie lewer dieselfde leë lys sonder dat 'n VPN betrokke is. Bewys dat die twee toestelle 'n segment deel voordat jy die tonnel blameer.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRDie eerste opdrag lys wat homself op die hulpmasjien se segment aankondig, en die tweede vra die multicast-DNS-groep direk. 'n Ontvanger wat in albei ontbreek, sal ook nie in 'n foonprogram verskyn nie, ongeag die foon se tonneltoestand. As die ontvanger sigbaar is vanaf 'n toestel wie se tonnel af is en onsigbaar vanaf een wie se tonnel aan is, het jy die fase en die oorsaak saam gevind.
'n LAN-uitsondering hou die tonnel aan die gang
Baie kliënte bied 'n plaaslikenetwerk-uitsondering wat die tonnel aktief laat terwyl plaaslike adresse toegelaat word. Gebruik daardie gedokumenteerde instelling eerder as om die kill switch of die hele firewall af te skakel, want dit verander veel meer as wat cast nodig het. As die netwerk slimtoestelle doelbewus skei, vra die eienaar vir die spesifieke ontdekking-, beheer- en terugkeerverkeer eerder as vir plat toegang.
nc -vz 192.168.1.50 8009'n Beheertoets teen die ontvanger skei toestemming van bereikbaarheid: 'n poort wat antwoord beteken die baan bestaan, terwyl 'n weiering beteken die foon mog die toestel ontdek en kan steeds nie met dit praat nie. Poorte 8008 en 8009 is die gewone cast-poorte, en 'n program kan ander gebruik, so hanteer 'n enkele geweierde poort as 'n wenk eerder as 'n uitspraak. Die uitsondering en die programtoestemming bly onafhanklik, want plaaslike toegang gee nie 'n roete nie en 'n roete byvoeg gee nie toestemming nie. 'n Kill switch kan ook plaaslike verkeer na 'n herverbinding laat val, daarom moet ontdekking weer getoets word sodra die tonnel terug is.
Weergawe gebruik dalk nie die foon se verbinding nie
In 'n programgerigte sessie gee die foon die ontvanger 'n media-adres en die ontvanger haal dit oor sy eie verbinding, dus verander die foon se publieke adres niks vir die stroom nie. 'n Rekeningbeperkte titel kan steeds om sy eie redes misluk, en Google se cast-vereistes dek program- en toestelversoenbaarheid eerder as die netwerkpad. Om die televisie self deur 'n tonnel te lei, is 'n aparte opset met sy eie beleidsvrae.
Twee leidrade onderskei die modi. 'n Cast wat die foon se skerm sluit oorleef, is programgerig, want die ontvanger haal op sy eie; 'n spieël wat stop wanneer die sender se skerm sluit, is 'n deurlopende stroom vanaf die foon. Wanneer ontdekking en beheer slaag maar weergawe vasval, kyk eerder na die ontvanger se Wi-Fi-skakel en sy internetpad, want 'n spoedtoets op die foon beskryf die foon en nie die televisie nie.
Maak die uitsondering ongedaan en toets weer
Elke tydelike verandering het 'n pad terug nodig, en die volgorde maak saak. Verwyder die LAN-uitsondering, herverbind die tonnel sodat die kliënt sy beleid weer toepas, herhaal dan die ontdekkingstap en let op of die ontvanger weer verdwyn. Daardie volgorde vertel jou of die uitsondering die werk gedoen het of of iets anders intussen verander het.
# 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'Verifieer die drie fases daarna afsonderlik, want 'n slaag op een sê niks oor die ander nie. Kontroleer dan dat onverwante foonprogramme steeds die beoogde roete volg, want 'n plaaslike uitsondering wat stilweg 'n volledige omleiding geword het, is 'n slegter uitkoms as 'n cast wat een ekstra tik nodig het.