Prečo prehrávanie prestane fungovať po zapnutí VPN na routeri
Zisťovanie ide cez link-local multicast, kým televízor si médiá sťahuje sám. Predvolené pravidlo politiky môže zachytiť LAN požiadavku a poslať ju do tunela.
Prehrávanie fungovalo pred zapnutím VPN na routeri a zlyhá hneď po ňom, kým bežné prehliadanie na telefóne stále funguje. Oba fakty sú v súlade, pretože prehrávanie nie je jedno spojenie. Telefón zisťuje a ovláda prijímač cez lokálnu sieť a potom si prijímač stiahne médiá cez vlastné spojenie.
Dve cesty, ktoré zlyhávajú odlišne
Riadiace spojenie je lokálne. Telefón nájde prijímač tak, že sa spýta lokálnej siete, a potom otvorí riadiace spojenie na adresu, ktorú sa dozvedel. Ak sa prijímač v zozname nikdy neobjaví, krok zisťovania zlyhal ešte pred požiadaním o akékoľvek médiá.
Cesta médií nemusí byť lokálna. Mnohé prijímače si tok sťahujú samy, cez vlastné spojenie a s vlastnými prihlasovacími údajmi, takže trasa telefónu neopisuje trasu prijímača. Telefón, ktorý vyzerá, že používa jeden výstup, nič nehovorí o tom, kam ide prevádzka televízora.
Toto rozdelenie je dôvod, prečo porucha vyzerá zvláštne. Tunel zmenil smerovaciu tabuľku telefónu a nezmenil tú televízora, preto symptóm, ktorý sa objaví na jednej strane páru, treba hľadať na tej strane. Skúmanie nesprávneho zariadenia je zvyčajný dôvod, prečo oprava vyzerá, akoby nič nerobila.
Prečo zisťovanie zlyhá ako prvé
Zisťovanie zvyčajne ide cez link-local multicast. mDNS odosiela na 224.0.0.251 cez UDP port 5353 a SSDP odosiela na 239.255.255.250 cez UDP port 1900. Oba sú z princípu obmedzené na jedno spojenie, preto ich router neposiela medzi segmentmi bez pomoci opakovača alebo proxy. Smerovaný VPN nerozširuje multicast skupinu a trasa politiky nedokáže spôsobiť, aby sa skupina, ktorá nikdy neopustila spojenie, objavila na inom.
Prvá porucha teda nemá nič spoločné so šifrovaním. Multicast telefónu opúšťa rozhranie, z ktorého bol odoslaný, prijímač je v segmente, ktorý ho nikdy nevidí, a zoznam zariadení sa vráti prázdny. Prázdny zoznam nie je dôkazom, že televízor stratil prístup na internet.
Izolácia vytvára rovnaký symptóm aj bez akéhokoľvek VPN. Hosťovské siete a izolácia klientov na prístupovom bode zámerne bránia zariadeniam rozprávať sa navzájom, a zapnutie VPN na routeri nad izolovaným segmentom na tom nič nemení. Skontrolujte nastavenie izolácie skôr, než skontrolujete tunel. Je to lacnejšia odpoveď a bežnejšia.
Rozloženie segmentov je druhá polovica. Druhý router, mesh uzol v inom režime alebo káblový segment za iným NAT umiestnia prijímač tam, kam sa prevádzka zisťovania telefónu nedostane.
Prečo predvolené pravidlo politiky môže prehltnúť lokálnu požiadavku
Router, ktorý posiela všetku prevádzku do tunela, nainštaluje predvolenú trasu na rozhraní tunela. Ak prefix LAN nie je z tejto politiky vylúčený, paket adresovaný zariadeniu dva metre ďaleko teraz zodpovedá predvolenej trase a router pošle riadiacu požiadavku do tunela namiesto na prepínač.
| 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 |
Poradie pravidiel rozhoduje o výsledku. Smerovanie podľa politiky hodnotí pravidlá v poradí priority, preto výnimka pre lokálny prefix musí stáť pred pravidlom, ktoré vyberá tabuľku tunela. Pridanie výnimky za pravidlom tunela nemá účinok, a preto konfigurácia, ktorá vyzerá správne, môže stále posielať LAN prevádzku na vzdialený výstup.
Oprava je úzka: povoľte konkrétne lokálne cieľe, ktoré tok prehrávania potrebuje, a zvyšok izolácie nechajte na pokoji. Odstránenie izolácie klientov ako prvý krok vylieči symptóm, ale zahodí kontrolu, ktorú sieť mala mať podľa návrhu.
Rýchla kontrola na telefóne určí, ktorá z dvoch porúch nastala. Ak trasa k prijímaču ukazuje na tunel, problémom je politika. Ak ukazuje na LAN a zisťovanie stále zlyháva, problémom je multicast alebo izolácia a žiadna zmena trasy nepomôže.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestujte krok, ktorý sa zmenil, nie krajinu
Zapísané pozorovania porážajú opakované experimenty. Poznačte, či sa prijímač objaví v zozname zariadení, či sa k nemu dostane riadiaca požiadavka a či sa prehrávanie spustí po výbere toku. Každá odpoveď odstraňuje jeden krok z podozrenia.
Potom testujte každý krok priamo, namiesto prepínania výstupných miest. Zmena krajiny VPN testuje cestu médií a kroky zisťovania a riadenia necháva nedotknuté, takže môže vyzerať, že náhodou pomohla, bez toho, aby vás niečo naučila.
Na strane prijímača skontrolujte jeho vlastnú trasu a stav jeho vlastného účtu. Televízor, ktorý si sťahuje médiá cez iný výstup ako telefón, je normálny návrh, a porucha tam je otázkou o sieťovej politike prijímača, nie o tuneli telefónu.
Zapíšte výsledok jednou vetou o tom, ktorý krok sa pokazil a čo ho zmenilo. Tá veta má väčšiu cenu než týždeň prepínania krajín a prežije aj ďalšiu aktualizáciu firmvéru.
Prehrávanie je dobrý testovací prípad pre všeobecné pravidlo o tuneloch. Keď sa do siete pridá tunel, prvá otázka je ktoré cieľe sa doň nikdy nemali dostať, a druhá je, ktoré z nich politika napriek tomu potichu prijala.