Cast stoppet op in VPN: ûntdekking, kontrôle of stream?
In ûntbrekkende ûntfanger, in wegere sesje en in stream dy't stûket mislearje op ferskillende plakken. Benefoarmje de faze foardat jo it VPN-belied fan 'e tillefoan of it netwurk feroarje.
Cast brekt op trije plakken dy't fan 'e bank ôf itselde lykje. De tillefoan sjocht de ûntfanger miskien nea, de ûntfanger kin ferskine en dan de sesje wegerje, of de sesje kin begjinne en in minút letter stûkje. In tunnel op 'e tillefoan feroaret elk fan dy paden oars, en foar ien fan har feroaret er hielendal neat. Benefoarmje earst de faze dy't mislearret en beslute dan oft in beliedswiziging wol de goede hefboom is.
Benefoarmje de faze dy't mislearret foardat jo it belied feroarje
Sjoch wat de tillefoan docht fuortendaliks nei't jo op it cast-piktogram tikke hawwe. In lege list is in ûntdekkingsresultaat, in tik dy't in flater meldt is in kontrêleresultaat, en in sesje dy't begjint foardat er stûket is in werjaveresultaat. Dy trije hawwe ferskillende eigners, en meastentiids binne allinnich de earste twa belutsen by de tunnel YNstellings fan 'e tillefoan.
| 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 |
Skriuw de faze op foardat jo wat feroarje. In repataasje tapast op 'e ferkearde faze makket de folgjende test ûnlêsber, en it measte cast-folksleau komt krekt út dy betizing.
Ûntdekking is lokaal ferkear, en in tunnel ferberget it
Untfangers meitsje harsels bekend fia lokale oankundigings en de tillefoan fynt se mei fragen op deselde keten, dus alles wat de tillefoan fan dy keten hellet, hellet de ûntfanger fan 'e list. In tunnel dy't al it ferkear by it LAN wei liedt, kin dy útwikselings ferbergje, en in lokale-netwurkfergunning op app-nivo kin se blokkearje sels as de rûte bestiet. Gaste-Wi-Fi mei kliïntisolaasje jout deselde lege list hielendal sûnder VPN. Bewiis dat de twa apparaten in segmint diele foardat jo de tunnel de skuld jouwe.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRIt earste kommando listet wat himsels oankundiget yn it segmint fan 'e helpmasine, en it twadde freget de multicast-DNS-groep direkt. In ûntfanger dy't yn beide ûntbrekt, sil ek net yn in tillefoanapp ferskine, wat de tunnelstân fan 'e tillefoan ek is. As de ûntfanger sichtber is fan in apparaat mei de tunnel út en ûnsichtber fan ien mei de tunnel oan, hawwe jo de faze en de oarsaak tegearre fûn.
In LAN-útsûndering hâldt de tunnel oan
In protte kliïnten biede in lokale-netwurkútsûndering oan dy't de tunnel aktyf lit wylst lokale adressen tastean wurde. Brûk dy dokumintearre ynstelling ynstee fan de kill switch of de hiele firewall út te setten, want dy feroarje folle mear as cast nedich hat. As it netwurk tûke apparaten mei sin skiedt, freegje de eigner dan om it spesifike ûntdekkings-, kontrôle- en weromferkear ynstee fan platte tagong.
nc -vz 192.168.1.50 8009In kontrôleproef tsjin 'e ûntfanger skiedt tastimming fan berikberens: in poarte dy't antwurdet betsjut dat it paad bestiet, wylst in wegering betsjut dat de tillefoan it apparaat ûntdekke mocht en der dochs net mei prate kin. Poarten 8008 en 8009 binne de gewoane cast-poarten, en in app kin oaren brûke, dus behannelje ien wegere poarte as in hint en net as in fûnis. De útsûndering en de app-tastimming bliuwe ûnôfhinklik, want lokale tagong makket gjin rûte en in rûte tafoegje jout gjin tastimming. In kill switch kin ek lokaal ferkear falle litte nei in werferbining, dêrom moat ûntdekking opnij test wurde sadree't de tunnel werom is.
Werjaver brûkt miskien net de ferbining fan 'e tillefoan
Yn in troch de app oanstjoerde sesje jout de tillefoan de ûntfanger in mediaadres en hellet de ûntfanger it oer syn eigen ferbining, dus it feroarjen fan it iepenbiere adres fan 'e tillefoan docht neat foar de stream. In titel beheind troch in akkount kin dochs om syn eigen redenen mislearje, en Google's cast-easken dekke app- en apparaatkompatibiliteit, net it netwurkpaad. De televyzje sels troch in tunnel liede is in aparte konfiguraasje mei eigen beliedsfragen.
Twa oanwizings skiede de modi. In cast dy't it beskoatteljen fan it tillefoanskerm oerlibbet is app-oanstjoerd, om't de ûntfanger sels hellet; in spegel dy't stopt as it skerm fan 'e stjoerder beskoattele wurdt is in trochgeande stream fan 'e tillefoan. As ûntdekking en kontrôle slagje mar werjaver stûket, sjoch dan nei de Wi-Fi-ferbining fan 'e ûntfanger en syn internetpaad, want in snelheidstest op 'e tillefoan beskriuwt de tillefoan en net de televyzje.
Meitsje de útsûndering ûngedien en test opnij
Elke tydlike feroaring hat in paad werom nedich, en de folchoarder is wichtich. Ferwiderje de LAN-útsûndering, ferbin de tunnel opnij sadat de kliïnt syn belied wer tapast, werhelje dan de ûntdekkingsstap en notearje oft de ûntfanger wer ferdwynt. Dy folchoarder fertelt jo oft de útsûndering it wurk die of oft der ûnderwilens wat oars feroare.
# 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'Kontrolearje dêrnei de trije fazen apart, want in slagje op ien seit neat oer de oaren. Kontrolearje dan oft net-besibbe tillefoanapps noch de bedoelde rûte folgje, want in lokale útsûndering dy't stil in folsleine omgong wurden is, is in slimmer útkomst as in cast dy't ien ekstra tik nedich hat.