Dlaczego przesyłanie przestaje działać po włączeniu VPN na routerze
Wykrywanie odbywa się przez multicast link-local, a telewizor sam pobiera multimedia. Domyślna reguła polityki może przechwycić żądanie LAN i wysłać je do tunelu.
Przesyłanie działało przed włączeniem VPN na routerze i przestaje działać zaraz po jego włączeniu, a zwykłe przeglądanie na telefonie nadal działa. Oba fakty są spójne, ponieważ przesyłanie nie jest jednym połączeniem. Telefon odnajduje i kontroluje odbiornik w sieci lokalnej, a następnie odbiornik pobiera multimedia przez własne połączenie.
Dwie ścieżki, które zawodzą inaczej
Ścieżka sterowania jest lokalna. Telefon znajduje odbiornik, pytając sieć lokalną, po czym otwiera połączenie sterujące do poznanego adresu. Jeśli odbiornik nigdy nie pojawi się na liście, etap wykrywania zawiódł, zanim zażądano jakichkolwiek multimediów.
Ścieżka multimediów nie musi być lokalna. Wiele odbiorników pobiera strumień samodzielnie, przez własne połączenie i z własnymi danymi logowania, więc trasa telefonu nie opisuje trasy odbiornika. Telefon, który wygląda na korzystający z jednego wyjścia, nic nie mówi o tym, dokąd trafia ruch telewizora.
To rozdzielenie sprawia, że awaria wygląda dziwnie. Tunel zmienił tablicę routingu telefonu, a nie zmienił tablicy telewizora, więc objaw widoczny po jednej stronie pary trzeba śledzić po tej stronie. Badanie niewłaściwego urządzenia to zwykły powód, dla którego naprawa wydaje się nic nie robić.
Dlaczego wykrywanie psuje się pierwsze
Wykrywanie zwykle odbywa się przez multicast link-local. mDNS wysyła na 224.0.0.251 na port UDP 5353, a SSDP wysyła na 239.255.255.250 na port UDP 1900. Oba są z założenia ograniczone do jednego łącza, dlatego router nie przekazuje ich między segmentami bez pomocy repeatera lub proxy. Rutowany VPN nie rozszerza grupy multicast, a trasa polityki nie może sprawić, by grupa, która nigdy nie opuściła łącza, pojawiła się na innym.
Pierwsza awaria nie ma więc nic wspólnego z szyfrowaniem. Multicast telefonu opuszcza interfejs, z którego został wysłany, odbiornik jest w segmencie, który go nigdy nie widzi, a lista urządzeń wraca pusta. Pusta lista nie jest dowodem, że telewizor stracił dostęp do internetu.
Izolacja daje identyczny objaw bez żadnego VPN. Sieci gościnne i izolacja klientów na punkcie dostępowym celowo uniemożliwiają urządzeniom rozmowę ze sobą, a włączenie VPN na routerze nad izolowanym segmentem niczego w tym nie zmienia. Sprawdź ustawienie izolacji, zanim sprawdzisz tunel. To tańsza odpowiedź i częstsza.
Układ segmentów to druga połowa. Drugi router, węzeł mesh w innym trybie albo przewodowy segment za innym NAT umieszczają odbiornik tam, gdzie ruch wykrywający telefonu nie dociera.
Dlaczego domyślna reguła polityki może połknąć lokalne żądanie
Router, który kieruje cały ruch do tunelu, instaluje trasę domyślną na interfejsie tunelu. Jeśli prefiks LAN nie jest wyłączony z tej polityki, pakiet zaadresowany do urządzenia dwa metry dalej pasuje teraz do trasy domyślnej, a router wysyła żądanie sterujące do tunelu zamiast do przełącznika.
| 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 |
Kolejność reguł rozstrzyga wynik. Routing polityki ocenia reguły w kolejności priorytetów, więc wyjątek dla lokalnego prefiksu musi stać przed regułą wybierającą tablicę tunelu. Dodanie wyjątku po regule tunelu nie daje efektu, dlatego konfiguracja wyglądająca poprawnie nadal może wysyłać ruch LAN do zdalnego wyjścia.
Naprawa jest wąska: zezwól na konkretne lokalne cele potrzebne przepływowi przesyłania i zostaw resztę izolacji w spokoju. Usunięcie izolacji klientów jako pierwszy krok leczy objaw, ale wyrzuca kontrolę, którą sieć miała z założenia.
Szybkie sprawdzenie na telefonie rozstrzyga, która z dwóch awarii występuje. Jeśli trasa do odbiornika wskazuje tunel, problemem jest polityka. Jeśli wskazuje LAN, a wykrywanie nadal zawodzi, problemem jest multicast lub izolacja i żadna zmiana trasy nie pomoże.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestuj etap, który się zmienił, a nie kraj
Zapisane obserwacje biją powtarzane eksperymenty. Zanotuj, czy odbiornik pojawia się na liście urządzeń, czy żądanie sterujące do niego dociera i czy odtwarzanie startuje po wybraniu strumienia. Każda odpowiedź usuwa jeden etap z podejrzeń.
Następnie testuj każdy etap bezpośrednio, zamiast zmieniać miejsce wyjścia. Zmiana kraju VPN testuje ścieżkę multimediów, a etapy wykrywania i sterowania pozostawia nietknięte, więc może przypadkiem wyglądać na pomocną, nie ucząc cię niczego.
Po stronie odbiornika sprawdź jego własną trasę i stan jego własnego konta. Telewizor, który pobiera multimedia innym wyjściem niż telefon, to normalna konstrukcja, a awaria tam jest pytaniem o politykę sieciową odbiornika, a nie o tunel telefonu.
Zapisz wynik jednym zdaniem: który etap się zepsuł i co go zmieniło. To zdanie jest warte więcej niż tydzień zmieniania krajów i przetrwa następną aktualizację oprogramowania.
Przesyłanie to dobry przypadek testowy dla ogólnej reguły dotyczącej tuneli. Gdy dodaje się tunel do sieci, pierwsze pytanie brzmi które cele nigdy nie powinny się w nim znaleźć, a drugie – które z nich polityka mimo to po cichu zaakceptowała.