Miért áll le a vetítés a router VPN bekapcsolása után
A felderítés helyi multicaston megy, miközben a tévé maga tölti le a médiát. Egy alapértelmezett házirend elkaphatja a LAN-kérést, és az alagútba küldheti.
A vetítés működött a router VPN bekapcsolása előtt, és azonnal utána megszűnik, miközben a telefonon a szokásos böngészés továbbra is működik. A két tény összeegyeztethető, mert a vetítés nem egyetlen kapcsolat. A telefon a helyi hálózaton keresztül fedezi fel és vezérli a vevőt, majd a vevő a saját kapcsolatán tölti le a médiát.
Két útvonal, amelyek különbözőképpen hibáznak
A vezérlési útvonal helyi. A telefon úgy találja meg a vevőt, hogy kérdezi a helyi hálózatot, majd vezérlőkapcsolatot nyit a megtanult címre. Ha a vevő soha nem jelenik meg a listában, a felderítési lépés már azelőtt meghiúsult, hogy bármilyen médiát kértek volna.
A média útvonala nem feltétlenül helyi. Sok vevő maga tölti le a streamet, a saját kapcsolatán és a saját hitelesítő adataival, ezért a telefon útvonala nem írja le a vevő útvonalát. Egy telefon, amely látszólag egy kimenetet használ, semmit sem mond arról, hová megy a tévé forgalma.
Ez a szétválás az oka, hogy a hiba furcsán néz ki. Az alagút megváltoztatta a telefon útvonaltáblázatát, a tévéét nem, ezért a páros egyik oldalán megjelenő tünetet azon az oldalon kell nyomon követni. A rossz eszköz nyomon követése a szokásos oka annak, hogy egy javítás úgy tűnik, nem tesz semmit.
Miért a felderítés hibázik először
A felderítés általában link-local multicaston megy. Az mDNS a 224.0.0.251 címre küld az UDP 5353 porton, az SSDP pedig a 239.255.255.250 címre az UDP 1900 porton. Mindkettő tervezés szerint egyetlen linkre korlátozódik, ezért a router ismétlő vagy proxy segítsége nélkül nem továbbítja őket szegmensek között. Az útválasztott VPN nem terjeszt ki egy multicast csoportot, és egy házirend-útvonal nem teheti meg, hogy egy linket soha el nem hagyó csoport egy másikon jelenjen meg.
Tehát az első hibának semmi köze a titkosításhoz. A telefon multicastja elhagyja azt az interfészt, amelyre küldték, a vevő olyan szegmensen van, amely soha nem látja, és az eszközlista üresen tér vissza. Az üres lista nem bizonyíték arra, hogy a tévé elvesztette az internetelérést.
Az elkülönítés ugyanazt a tünetet hozza létre VPN nélkül is. A vendéghálózatok és az elérési pontok ügyfél-elkülönítése szándékosan megakadályozza, hogy az eszközök beszéljenek egymással, és az elkülönített szegmens fölött bekapcsolt router VPN ezen mit sem változtat. Ellenőrizze az elkülönítési beállítást az alagút előtt. Ez az olcsóbb válasz és a gyakoribb.
A szegmensek elrendezése a másik fél. Egy második router, egy másik módban működő mesh csomópont vagy egy újabb NAT mögötti vezetékes szegmens mind oda helyezi a vevőt, ahová a telefon felderítési forgalma nem jut el.
Miért nyelheti el egy alapértelmezett házirend a helyi kérést
Az a router, amely minden forgalmat alagútba irányít, alapértelmezett útvonalat telepít az alagút interfészére. Ha a LAN előtagja nincs kizárva abból a házirendből, a két méterre lévő eszköznek címzett csomag most megfelel az alapértelmezettnek, és a router a vezérlőkérést az alagútba küldi a kapcsoló helyett.
| 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 |
A szabályok sorrendje dönt az eredményről. A házirend-alapú útválasztás prioritási sorrendben értékeli a szabályokat, ezért a helyi előtag kivételének azelőtt kell szerepelnie, mint az alagút táblázatát kiválasztó szabálynak. A kivétel alagútszabály utáni hozzáadása hatástalan, ezért egy helyesnek látszó konfiguráció továbbra is küldhet LAN-forgalmat egy távoli kimenetre.
A javítás szűk: engedélyezze azokat a konkrét helyi célokat, amelyekre a vetítési folyamatnak szüksége van, a többi elkülönítést pedig hagyja békén. Az ügyfél-elkülönítés első lépésként való eltávolítása megszünteti a tünetet, de eldobja azt a vezérlést, amelyre a hálózatot tervezték.
A telefonon végzett gyors ellenőrzés eldönti, melyik hibáról van szó. Ha a vevő felé vezető útvonal az alagútra mutat, a házirend a probléma. Ha a LAN-ra mutat és a felderítés továbbra is meghiúsul, a multicast vagy az elkülönítés a probléma, és semmilyen útvonalváltozás nem segít.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpA megváltozott lépést tesztelje, ne az országot
A rögzített megfigyelések többet érnek az ismételt kísérleteknél. Jegyezze fel, megjelenik-e a vevő az eszközlistán, eljut-e hozzá vezérlőkérés, és elindul-e a lejátszás a stream kiválasztása után. Minden válasz egy lépést kivesz a gyanúból.
Utána közvetlenül tesztelje az egyes lépéseket, ne a kimeneti helyeket váltogassa. A VPN-ország váltása a média útvonalát teszteli, a felderítési és vezérlési lépéseket érintetlenül hagyja, ezért véletlenül segíteni látszhat anélkül, hogy bármit megtanítana.
A vevő oldalán ellenőrizze a saját útvonalát és a saját fiókja állapotát. Az a tévé, amely más kimeneten keresztül tölti le a médiát, mint a telefon, normális tervezés, és az ottani hiba a vevő hálózati házirendjének kérdése, nem a telefon alagútjáé.
Írja le az eredményt egyetlen mondatban arról, melyik lépés tört el és mi változtatta meg. Az a mondat többet ér egy hét országváltásnál, és túléli a következő firmware-frissítést.
A vetítés jó teszteset az alagutakra vonatkozó általános szabályhoz. Amikor egy hálózathoz alagutat adnak, az első kérdés az, mely céloknak nem lett volna szabad soha belekerülniük. A második az, hogy melyeket fogadott el a házirend mégis csendben.