Přenos se zastaví na VPN: zjišťování, ovládání, nebo stream?
Chybějící přijímač, odmítnutá relace a zaseknutý stream selhávají na různých místech. Pojmenujte fázi dřív, než změníte VPN politiku telefonu nebo síť.
Přenos se láme na třech místech, která z gauče vypadají stejně. Telefon nemusí přijímač nikdy vidět, přijímač se může objevit a pak relaci odmítnout, nebo relace může začít a o minutu později se zaseknout. Tunel v telefonu mění každou z těchto cest jinak a u jedné z nich nemění vůbec nic. Nejprve pojmenujte selhávající fázi a teprve pak rozhodněte, zda je změna politiky vůbec správnou pákou.
Pojmenujte selhávající fázi, než změníte politiku
Sledujte, co telefon udělá hned po klepnutí na ikonu přenosu. Prázdný seznam je výsledek zjišťování, klepnutí, které ohlásí chybu, je výsledek ovládání a relace, která začne před zaseknutím, je výsledek přehrávání. Tyto tři mají různé vlastníky a obvykle jen první dva zahrnují nastavení tunelu v telefonu.
| 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 |
Zapište si fázi, než cokoli změníte. Oprava použitá na špatnou fázi dělá další test nečitelným a většina přenosových pověstí vzniká právě z tohoto zmatení.
Zjišťování je místní provoz a tunel ho skrývá
Přijímače se ohlašují místními oznámeními a telefon je nachází dotazy na stejném spoji, takže cokoli, co telefon z tohoto spoje odstraní, odstraní i přijímač ze seznamu. Tunel, který směruje veškerý provoz mimo LAN, může tyto výměny skrýt a oprávnění k místní síti na úrovni aplikace je může zablokovat, i když trasa existuje. Hostující Wi-Fi s izolací klientů vytváří stejný prázdný seznam úplně bez VPN. Dřív než obviníte tunel, dokažte, že obě zařízení sdílejí segment.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR
První příkaz vypíše, co se ohlašuje v segmentu pomocného stroje, a druhý se přímo ptá skupiny multicast DNS. Přijímač, který chybí v obou, se neobjeví ani v aplikaci v telefonu, ať je stav tunelu jakýkoli. Pokud je přijímač vidět ze zařízení s vypnutým tunelem a není vidět ze zařízení se zapnutým, našli jste fázi i příčinu zároveň.
Výjimka pro LAN udržuje tunel zapnutý
Mnoho klientů nabízí výjimku pro místní síť, která nechává tunel aktivní a přitom povoluje místní adresy. Použijte toto zdokumentované nastavení místo vypínání kill switch nebo celého firewallu, protože ty mění mnohem víc, než přenos potřebuje. Pokud síť záměrně odděluje chytrá zařízení, požádejte vlastníka o konkrétní provoz zjišťování, ovládání a návratu místo plochého přístupu.
nc -vz 192.168.1.50 8009
Ovládací test proti přijímači odděluje oprávnění od dosažitelnosti: port, který odpovídá, znamená, že cesta existuje, kdežto odmítnutí znamená, že telefon směl zařízení objevit a přesto s ním nemůže mluvit. Porty 8008 a 8009 jsou obvyklé porty přenosu a aplikace může používat jiné, proto berte jeden odmítnutý port jako nápovědu, ne jako rozsudek. Výjimka a oprávnění aplikace zůstávají nezávislé, protože místní přístup nevytváří trasu a přidání trasy nedává oprávnění. Kill switch může po opětovném připojení zahodit i místní provoz, a proto se zjišťování musí po návratu tunelu znovu otestovat.
Přehrávání nemusí používat připojení telefonu
V relaci řízené aplikací předá telefon přijímači adresu média a přijímač si ji stáhne přes vlastní připojení, takže změna veřejné adresy telefonu pro stream nic nedělá. Titul omezený účtem může selhat i z vlastních důvodů a požadavky na přenos od Googlu pokrývají kompatibilitu aplikace a zařízení, ne síťovou cestu. Směrování samotného televizoru tunelem je samostatná konfigurace s vlastními otázkami politiky.
Dvě stopy oba režimy rozlišují. Přenos, který přežije uzamčení obrazovky telefonu, je řízený aplikací, protože přijímač stahuje sám; zrcadlení, které se zastaví při uzamčení obrazovky odesílatele, je nepřetržitý stream z telefonu. Když zjišťování a ovládání uspějí, ale přehrávání se zasekne, dívejte se raději na Wi-Fi spoj přijímače a jeho cestu do internetu, protože test rychlosti v telefonu popisuje telefon, ne televizor.
Výjimku zrušte a otestujte znovu
Každá dočasná změna potřebuje cestu zpět a na pořadí záleží. Odstraňte výjimku pro LAN, znovu připojte tunel, aby klient znovu použil svou politiku, pak zopakujte krok zjišťování a poznamenejte, zda přijímač zase zmizí. Tato posloupnost říká, zda práci dělala výjimka, nebo zda se mezitím změnilo něco jiného.
# 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'
Poté ověřte tři fáze odděleně, protože úspěch v jedné nic neříká o ostatních. Pak zkontrolujte, že nesouvisející aplikace v telefonu stále jdou zamýšlenou trasou, protože místní výjimka, která se tiše stala úplným obchvatem, je horší výsledek než přenos, který potřebuje jedno klepnutí navíc.