Miksi castaus lakkaa toimimasta, kun otat reitittimen VPN:n käyttöön
Löytäminen kulkee paikallisen multicastin kautta, kun taas televisio hakee mediaa itse. Oletuskäytäntö voi kaapata lähiverkon pyynnön ja lähettää sen tunneliin.
Castaus toimi ennen reitittimen VPN:n käyttöönottoa ja epäonnistuu heti sen jälkeen, kun taas tavallinen selailu puhelimessa toimii edelleen. Molemmat tosiasiat ovat yhtäpitäviä, sillä castaus ei ole yksi yhteys. Puhelin löytää vastaanottimen ja ohjaa sitä lähiverkon kautta, ja vastaanotin hakee sitten median oman yhteytensä kautta.
Kaksi polkua, jotka epäonnistuvat eri tavoin
Ohjauspolku on paikallinen. Puhelin löytää vastaanottimen kysymällä lähiverkolta ja avaa sitten ohjausyhteyden oppimaansa osoitteeseen. Jos vastaanotin ei koskaan ilmesty luetteloon, löytämisvaihe epäonnistui ennen kuin mitään mediaa pyydettiin.
Mediapolku ei ole välttämättä paikallinen. Monet vastaanottimet hakevat striimin itse, oman yhteytensä ja omien tunnistetietojensa kautta, joten puhelimen reitti ei kuvaa vastaanottimen reittiä. Puhelin, joka näyttää käyttävän yhtä ulostuloa, ei kerro mitään siitä, mihin television liikenne menee.
Juuri tämä kahtiajako saa vian näyttämään oudolta. Tunneli muutti puhelimen reititystaulukon eikä muuttanut television vastaavaa, joten parin toisella puolella ilmenevä oire on jäljitettävä siltä puolelta. Väärän laitteen jäljittäminen on tavallinen syy sille, että korjaus näyttää tekevän ei mitään.
Miksi löytäminen hajoaa ensin
Löytäminen kulkee yleensä linkkipaikallisen multicastin kautta. mDNS lähettää osoitteeseen 224.0.0.251 UDP-portille 5353, ja SSDP lähettää osoitteeseen 239.255.255.250 UDP-portille 1900. Molemmat on suunniteltu rajatuiksi yhteen linkkiin, minkä vuoksi reititin ei välitä niitä segmenttien välillä ilman toistimen tai välityspalvelimen apua. Reititetty VPN ei laajenna multicast-ryhmää, eikä käytäntöreitti voi saada linkin jättämätöntä ryhmää ilmestymään toiselle.
Ensimmäisellä vialla ei siis ole mitään tekemistä salauksen kanssa. Puhelimen multicast poistuu liitännästä, jolle se lähetettiin, vastaanotin on segmentissä, joka ei näe sitä koskaan, ja laiteluettelo palaa tyhjänä. Tyhjä luettelo ei ole todiste siitä, että televisio menetti internetyhteyden.
Eristäminen tuottaa saman oireen ilman mitään VPN:ää. Vierasverkot ja tukiasemien asiakaseristäminen estävät tarkoituksella laitteita puhumasta keskenään, eikä reitittimen VPN:n kytkeminen eristetyn segmentin päälle muuta siinä mitään. Tarkista eristysasetus ennen tunnelia. Se on halvempi vastaus ja yleisempi.
Segmenttien sijoittelu on toinen puoli. Toinen reititin, eri tilassa oleva mesh-solmu tai kaapelisegmentti toisen NAT:n takana sijoittavat kaikki vastaanottimen sinne, minne puhelimen löytämisliikenne ei yllä.
Miksi oletuskäytäntö voi niellä paikallisen pyynnön
Reititin, joka ohjaa kaiken liikenteen tunneliin, asentaa oletusreitin tunnelin liitäntään. Jos lähiverkon etuliitettä ei ole jätetty tämän käytännön ulkopuolelle, kahden metrin päässä olevaan laitteeseen osoitettu paketti vastaa nyt oletusta, ja reititin lähettää ohjauspyynnön tunneliin kytkimen sijaan.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Sääntöjen järjestys ratkaisee tuloksen. Käytäntöreititys arvioi sääntöjä prioriteettijärjestyksessä, joten paikallisen etuliitteen poikkeuksen on oltava ennen sääntöä, joka valitsee tunnelin taulukon. Poikkeuksen lisääminen tunnelisäännön jälkeen ei vaikuta mitenkään, minkä vuoksi oikealta näyttävä kokoonpano voi silti lähettää lähiverkon liikennettä etäiseen ulostuloon.
Korjaus on kapea: salli ne tietyt paikalliset kohteet, joita castausvirta tarvitsee, ja jätä muu eristäminen rauhaan. Asiakaseristyksen poistaminen ensimmäisenä vaiheena korjaa oireen mutta heittää pois hallinnan, jota varten verkko oli suunniteltu.
Nopea tarkistus puhelimessa selvittää, kumpi kahdesta viasta sinulla on. Jos reitti vastaanottimeen osoittaa tunneliin, ongelma on käytännössä. Jos se osoittaa lähiverkkoon ja löytäminen epäonnistuu edelleen, ongelma on multicastissa tai eristämisessä, eikä mikään reittimuutos auta.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestaa vaihetta, joka muuttui, älä maata
Kirjatut havainnot ovat arvokkaampia kuin toistuvat kokeet. Kirjaa, ilmestyykö vastaanotin laiteluetteloon, saapuuko ohjauspyyntö sille ja alkaako toisto, kun striimi valitaan. Jokainen vastaus poistaa yhden vaiheen epäilyksistä.
Testaa sitten jokaista vaihetta suoraan sen sijaan, että vaihtaisit ulostulosijaintia. VPN-maan vaihtaminen testaa mediapolun ja jättää löytämis- ja ohjausvaiheet koskemattomiksi, joten se voi näyttää sattumalta auttavan opettamatta sinulle mitään.
Tarkista vastaanottimen puolella sen oma reitti ja sen oman tilin tila. Televisio, joka hakee mediaa eri ulostulosta kuin puhelin, on normaali rakenne, ja vika siellä on kysymys vastaanottimen verkkokäytännöstä eikä puhelimen tunnelista.
Kirjoita tulos yhdeksi lauseeksi siitä, mikä vaihe hajosi ja mikä sen muutti. Se lause on arvokkaampi kuin viikko maan vaihtamista, ja se kestää seuraavan laiteohjelmistopäivityksen.
Castaus on hyvä testitapaus yleiselle tunnelisäännölle. Kun verkkoon lisätään tunneli, ensimmäinen kysymys on mitkä kohteet eivät olisi koskaan saaneet tulla siihen. Toinen on, mitkä niistä käytäntö silti hyväksyi hiljaa.