Przesyłanie obrazu przez VPN: wykrywanie, sterowanie czy strumień?

Przesyłanie obrazu psuje się w trzech miejscach, które z kanapy wyglądają identycznie. Telefon może nigdy nie zobaczyć odbiornika, odbiornik może się pojawić i potem odrzucić sesję, albo sesja może się rozpocząć i zatrzymać minutę później. Tunel na telefonie zmienia każdą z tych ścieżek inaczej, a jednej z nich nie zmienia wcale. Najpierw nazwij zawodzący etap, a potem zdecyduj, czy zmiana polityki jest w ogóle właściwą dźwignią.

Nazwij zawodzący etap, zanim zmienisz politykę

Obserwuj, co telefon robi zaraz po dotknięciu ikony przesyłania. Pusta lista to wynik wykrywania, dotknięcie zgłaszające błąd to wynik sterowania, a sesja, która startuje, zanim się zatnie, to wynik odtwarzania. Te trzy mają różnych właścicieli i zwykle tylko pierwsze dwa dotyczą ustawień tunelu telefonu.

Zapisz etap, zanim cokolwiek zmienisz. Poprawka zastosowana na niewłaściwym etapie czyni następny test nieczytelnym, a większość opowieści o przesyłaniu bierze się właśnie z tego zamieszania.

Wykrywanie to ruch lokalny, a tunel go ukrywa

Odbiorniki reklamują się lokalnymi ogłoszeniami, a telefon znajduje je zapytaniami w tym samym łączu, więc wszystko, co usuwa telefon z tego łącza, usuwa odbiornik z listy. Tunel kierujący cały ruch poza LAN może ukryć te wymiany, a uprawnienie do sieci lokalnej na poziomie aplikacji może je zablokować nawet wtedy, gdy trasa istnieje. Wi-Fi dla gości z izolacją klientów daje tę samą pustą listę bez żadnego VPN. Udowodnij, że oba urządzenia dzielą segment, zanim obwinisz tunel.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Pierwsze polecenie wymienia to, co ogłasza się w segmencie maszyny pomocniczej, a drugie pyta grupę multicast DNS bezpośrednio. Odbiornik nieobecny w obu nie pojawi się też w aplikacji telefonu, niezależnie od stanu tunelu. Jeśli odbiornik jest widoczny z urządzenia z wyłączonym tunelem, a niewidoczny z urządzenia z włączonym tunelem, znalazłeś etap i przyczynę naraz.

Wyjątek LAN utrzymuje tunel włączony

Wiele klientów oferuje wyjątek sieci lokalnej, który zostawia tunel aktywny, pozwalając na adresy lokalne. Użyj tego udokumentowanego ustawienia zamiast wyłączać kill switch albo cały firewall, bo tamte zmieniają znacznie więcej, niż potrzebuje przesyłanie. Jeśli sieć celowo rozdziela urządzenia inteligentne, poproś właściciela o konkretny ruch wykrywania, sterowania i powrotny, a nie o płaski dostęp.

nc -vz 192.168.1.50 8009

Test sterowania do odbiornika oddziela uprawnienie od osiągalności: port, który odpowiada, oznacza, że ścieżka istnieje, a odmowa oznacza, że telefon mógł wykryć urządzenie i nadal nie może się z nim porozumieć. Porty 8008 i 8009 to zwykłe porty przesyłania, a aplikacja może używać innych, więc jeden odrzucony port traktuj jako wskazówkę, nie wyrok. Wyjątek i uprawnienie aplikacji pozostają niezależne, bo dostęp lokalny nie tworzy trasy, a dodanie trasy nie daje uprawnienia. Kill switch może też porzucić ruch lokalny po ponownym połączeniu, dlatego wykrywanie trzeba sprawdzić ponownie, gdy tunel wróci.

Odtwarzanie może nie korzystać z łącza telefonu

W sesji kierowanej przez aplikację telefon przekazuje odbiornikowi adres mediów, a odbiornik pobiera go przez własne łącze, więc zmiana publicznego adresu telefonu nic nie daje strumieniowi. Tytuł ograniczony kontem nadal może zawieść z własnych powodów, a wymagania Google dotyczące przesyłania obejmują zgodność aplikacji i urządzenia, a nie ścieżkę sieciową. Kierowanie samego telewizora przez tunel to osobna konfiguracja z własnymi pytaniami o politykę.

Dwie wskazówki rozróżniają tryby. Przesyłanie, które trwa po zablokowaniu ekranu telefonu, jest kierowane przez aplikację, bo odbiornik pobiera sam; lustrzenie, które zatrzymuje się, gdy ekran nadawcy się zablokuje, to ciągły strumień z telefonu. Gdy wykrywanie i sterowanie się udają, a odtwarzanie się zatyka, patrz na łącze Wi-Fi odbiornika i jego ścieżkę do internetu, bo test prędkości na telefonie opisuje telefon, a nie telewizor.

Wycofaj wyjątek i sprawdź ponownie

Każda tymczasowa zmiana potrzebuje drogi powrotu, a kolejność ma znaczenie. Usuń wyjątek LAN, połącz tunel ponownie, aby klient zastosował swoją politykę, potem powtórz krok wykrywania i zanotuj, czy odbiornik znów znika. Ta sekwencja mówi, czy wyjątek wykonywał pracę, czy coś innego zmieniło się pomiędzy.

# 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'

Potem sprawdź trzy etapy osobno, bo powodzenie jednego nic nie mówi o pozostałych. Następnie sprawdź, czy niezwiązane aplikacje telefonu nadal idą zamierzoną trasą, bo lokalny wyjątek, który po cichu stał się pełnym obejściem, to gorszy wynik niż przesyłanie wymagające jednego dodatkowego dotknięcia.