Wykrywanie Chromecast i DLNA nigdy nie przechodzi przez routowany VPN

Przycisk przesyłania nic nie wyświetla, VLC DLNA pozostaje pusty, a maszyna po drugiej stronie odpowiada na ping bez skarg. Ta kombinacja nie jest problemem z przepustowością ani zagadką firewalla. Wykrywanie w tych protokołach to wymiana grupowa w segmencie lokalnym, i routowany tunel nie przenosi ruchu adresowanego grupowo. Sesja, którą próbujesz rozpocząć, nigdy nie zostaje zaproponowana.

Osiągalność jest w porządku. Brakuje wykrywania.

Mit: tunel potrzebuje ustawienia albo większej przepustowości

Typowe propozycje to włączenie ruchu peer-to-peer, podniesienie MTU albo zmiana typu urządzenia tunelu. Żadna z nich nie dodaje domeny rozgłoszeniowej. Multicast dostarczają przełączniki i lokalny stos sieciowy, a interfejs TUN punkt-punkt nie ma adresu grupowego, który mógłby zalać.

Zmiana ustawień może sprawić, że awaria będzie głośniejsza. Nie może jednak sprawić, by ogłoszenie pojawiło się tam, gdzie protokół nigdy go nie wysłał.

Czym naprawdę jest wymiana wykrywania

Trzy wzorce obejmują prawie wszystko, co napotkasz. mDNS wysyła do 224.0.0.251 przez UDP 5353, SSDP wysyła do 239.255.255.250 przez UDP 1900, a starsze listy przeglądania SMB trafiały na adres rozgłoszeniowy podsieci. Każda jest adresowana do grupy, a nie do hosta, i każda oczekuje odbiorcy w tym samym segmencie. Odbiorca po drugiej stronie routowanego tunelu nie jest w tym segmencie, więc nic nie dociera.

Nawet przekazane ogłoszenie niesie ładunek: zwykle adres LAN i port nadawcy, do których zdalny widz musi potem dotrzeć.

Przeczytaj zrzut przed zmianą tunelu

Przechwytuj na interfejsie tunelu, gdy aplikacja skanuje. Pusty zrzut oznacza, że ogłoszenie nigdy nie przekroczyło granicy, i żadne strojenie tunelu tego nie zmieni. Pakiety, które jednak się pojawiają, gdy aplikacja wciąż nic nie pokazuje, zwykle oznaczają, że ogłoszony adres jest nieosiągalny od strony widza, czyli problem routingu w kostiumie wykrywania.

Dwie minuty zrzutu zastępują godzinę zgadywania na temat portów: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Trzy rozwiązania, najtańsze pierwsze

Wskaż klientowi bezpośrednio adres usługi. Dla DLNA, SMB i prostych serwerów multimediów pomija to wykrywanie całkowicie i dowodzi, że ścieżka ładunku działa, co czyni to najlepszym pierwszym testem, a zarazem użytecznym obejściem. Chromecast jest wyjątkiem, bo odbiornik oczekuje, że zostanie znaleziony, a nie zaadresowany.

Przekazuj protokół na bramie. Reflektor mDNS powtarza ogłoszenia między tunelem a siecią LAN, a Avahi dostarcza sekcję reflektora, która przyjmuje jawną listę interfejsów. Utrzymuj przekazywanie wąsko i potwierdź, że ogłoszony adres jest osiągalny z obu stron, inaczej odpowiedź nadal wskazuje podsieć, do której widz nie może routować.

Mostkuj zamiast routować. Segment TAP, w którym serwer mostkuje urządzenie tap do sieci LAN, umieszcza oba końce w jednej domenie rozgłoszeniowej, więc ogłoszenia przechodzą bez zmian. To także najdroższa opcja, bo jedna podsieć oznacza jedną domenę awarii, a każda usługa multicast w sieci LAN dociera teraz do każdego peera.

Co nie pomaga, choćby proponowano to najczęściej

Przełączenie dev tun na dev tap bez mostka pozostawia urządzenie TAP, które nadal jest routowane, więc zachowanie się nie zmienia. client-to-client pozwala na unicast między peerami i nie zalewa rozgłoszeń. Przekazanie portu wykrywania do jednego hosta nie dostarcza ruchu adresowanego grupowo. Serwer multimediów przypisany do jednego adresu odpowiada dalej na tym adresie, dopóki jego własna konfiguracja nie wymieni interfejsu VPN.

Przetestuj jedno bezpośrednie żądanie unicast, potem jedno ogłoszone żądanie. Jeśli pierwsze działa, a drugie nie, tunel jest zdrowy i wykrywanie to cały problem.