Proč přestane fungovat odesílání do televize po zapnutí VPN v routeru
Zjišťování probíhá přes lokální multicast, zatímco televize si média stahuje sama. Výchozí politika může zachytit požadavek do místní sítě a poslat ho do tunelu.
Odesílání fungovalo před zapnutím VPN v routeru a hned potom přestalo, zatímco běžné procházení na telefonu dál funguje. Obě skutečnosti jsou slučitelné, protože odesílání není jedno spojení. Telefon najde přijímač a ovládá ho přes místní síť a přijímač si pak média stahuje přes vlastní spojení.
Dvě cesty, které selhávají různě
Řídicí cesta je lokální. Telefon najde přijímač tak, že se zeptá místní sítě, a pak otevře řídicí spojení na adresu, kterou zjistil. Pokud se přijímač v seznamu nikdy neobjeví, krok zjišťování selhal dřív, než byla vyžádána jakákoli média.
Cesta médií nemusí být lokální. Mnoho přijímačů si tok stahuje samo, přes vlastní spojení a s vlastními přihlašovacími údaji, takže trasa telefonu nepopisuje trasu přijímače. Telefon, který zjevně používá jeden výstup, neříká nic o tom, kam jde provoz televize.
Právě toto rozdělení dělá poruchu podivnou. Tunel změnil směrovací tabulku telefonu a nezměnil tabulku televize, takže příznak, který se objeví na jedné straně dvojice, je třeba vysledovat na této straně. Sledování špatného zařízení je obvyklý důvod, proč se zdá, že oprava nic nedělá.
Proč zjišťování selhává jako první
Zjišťování obvykle jde přes link-local multicast. mDNS posílá na 224.0.0.251 na UDP portu 5353 a SSDP posílá na 239.255.255.250 na UDP portu 1900. Oba jsou podle návrhu omezené na jedno spojení, a proto je router nepředává mezi segmenty bez pomoci opakovače nebo proxy. Směrovaná VPN nerozšiřuje multicastovou skupinu a politika směrování nemůže způsobit, aby se skupina, která nikdy neopustila spojení, objevila na jiném.
První selhání tedy nemá nic společného se šifrováním. Multicast telefonu opouští rozhraní, na které byl odeslán, přijímač je v segmentu, který ho nikdy nevidí, a seznam zařízení se vrací prázdný. Prázdný seznam není důkaz, že televize ztratila přístup k internetu.
Izolace vytváří stejný příznak bez jakékoli VPN. Sítě pro hosty a izolace klientů na přístupových bodech záměrně brání zařízením mluvit spolu a zapnutí VPN v routeru nad izolovaným segmentem na tom nic nemění. Zkontrolujte nastavení izolace dřív než tunel. Je to levnější odpověď a ta častější.
Rozvržení segmentů je druhá polovina. Druhý router, mesh uzel v jiném režimu nebo kabelový segment za dalším NAT umisťují přijímač tam, kam se provoz zjišťování z telefonu nedostane.
Proč může výchozí politika spolknout lokální požadavek
Router, který směruje veškerý provoz do tunelu, nainstaluje výchozí trasu na rozhraní tunelu. Pokud není předpona místní sítě z této politiky vyloučena, paket adresovaný zařízení dva metry daleko teď odpovídá výchozí trase a router pošle řídicí požadavek do tunelu místo na switch.
| 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 |
O výsledku rozhoduje pořadí pravidel. Směrování podle politiky vyhodnocuje pravidla v pořadí priority, takže výjimka pro místní předponu musí být uvedena před pravidlem, které vybírá tabulku tunelu. Přidání výjimky za pravidlo tunelu nemá žádný účinek, a proto může konfigurace, která vypadá správně, přesto posílat provoz místní sítě na vzdálený výstup.
Oprava je úzká: povolte konkrétní místní cíle, které tok odesílání potřebuje, a zbytek izolace nechte být. Odstranění izolace klientů jako první krok opraví příznak, ale zahodí kontrolu, kterou síť měla mít.
Rychlý dotaz na telefonu rozhodne, kterou ze dvou poruch máte. Pokud trasa k přijímači ukazuje do tunelu, problém je v politice. Pokud ukazuje do místní sítě a zjišťování stále selhává, problém je v multicastu nebo izolaci a žádná změna trasy nepomůže.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestujte krok, který se změnil, ne zemi
Zaznamenaná pozorování mají větší cenu než opakované experimenty. Poznamenejte, zda se přijímač objevuje v seznamu zařízení, zda k němu dorazí řídicí požadavek a zda se přehrávání spustí po výběru toku. Každá odpověď odebere jeden krok z podezření.
Pak testujte každý krok přímo, místo abyste přepínali výstupy. Změna země VPN testuje cestu médií a kroky zjišťování a řízení nechává nedotčené, takže může náhodou vypadat jako pomoc, aniž by vás něčemu naučila.
Na straně přijímače zkontrolujte jeho vlastní trasu a stav účtu. Televize, která stahuje média přes jiný výstup než telefon, je normální návrh a porucha tam je otázkou síťové politiky přijímače, ne tunelu telefonu.
Zapište výsledek jednou větou o tom, který krok se pokazil a co ho změnilo. Ta věta má větší cenu než týden přepínání zemí a přežije další aktualizaci firmwaru.
Odesílání je dobrý testovací případ pro obecné pravidlo o tunelech. Když se do sítě přidá tunel, první otázka je které cíle do něj nikdy neměly vstoupit. Druhá je, které z nich politika přesto tiše přijala.