Dlaczego zdalny dostęp Plex nie działa za VPN i jak to naprawić

Zdalny dostęp przełącza się na niedostępny w chwili, gdy VPN przejmuje trasę domyślną, podczas gdy ten sam serwer nadal bez skargi strumieniuje do sieci LAN. Nic w logach Plex nie wyjaśnia zmiany, bo Plex nie jest częścią, która się zepsuła: publikuje adres, do którego ruch już nie dociera. Dostawca, który dzieli jeden publiczny adres między klientami, przekierowuje port na adres twojego tunelu, a coś na twojej własnej maszynie nadal musi przenieść ten port do odbiornika Plex. Wszystkie trzy ogniwa muszą zgodzić się co do jednego portu zewnętrznego, zanim test osiągalności zmieni się na zielony.

Łańcuch ma trzy ogniwa, a Plex widzi tylko ostatnie

Dostawca posiada publiczny adres i mapuje jeden ze swoich portów na adres twojego tunelu. Twoja maszyna bierze wszystko, co przychodzi na ten port, i przekierowuje to do odbiornika Plex, który zwykle siedzi na porcie pętli zwrotnej 32400. Potem Plexowi podaje się numer portu zewnętrznego, aby jego własna próba zgadzała się z tym, co wybiera świat zewnętrzny.

Przerwij choć jedno ogniwo, a interfejs webowy zgłasza zdalny dostęp jako niedostępny, bez najmniejszej wskazówki, które ogniwo zawiodło. Ta cisza jest powodem, dla którego ludzie restartują serwer, reinstalują aplikację i przełączają ustawienie w kółko, nie ruszając wskazówki. Trzy ogniwa zawodzą niezależnie: przekierowanie wycelowane w nieaktualny adres tunelu, przekierowanie obejmujące tylko interfejs Ethernet i pole Plex wciąż trzymające 32400 dają ten sam czerwony tekst. Pracuj od odbiornika na zewnątrz zamiast zgadywać, a uszkodzone ogniwo zwykle samo się nazywa w ciągu minuty.

Pierwsze ogniwo: przekieruj port u dostawcy VPN

Otwórz stronę przekierowywania portów dostawcy i dodaj mapowanie. Większość implementacji daje losowy port zewnętrzny i pozwala wybrać wewnętrzny, więc przyjmij przydział i skieruj go na adres tunelu, który twój klient ma obecnie. Zapisz ten numer, bo każdy kolejny krok powtarza go dokładnie.

Dostawcy, którzy rotują mapowanie przy ponownym połączeniu, są zwykłym powodem, dla którego ta konfiguracja przetrwa wieczór, a potem umiera. Niektórzy pozwalają poprosić o stabilny port, inni przydzielają nowy przy każdym uścisku dłoni, więc przeczytaj bieżącą stronę mapowania, zanim dotkniesz czegokolwiek innego.

Drugie ogniwo: przekieruj port za pomocą kotwicy pf

W macOS przekierowanie należy do kotwicy pf, jedna reguła na każdy interfejs, który może nieść pakiet. Najpierw napisz regułę tunelu, potem regułę Ethernet, z tym samym portem zewnętrznym w obu, inaczej ruch przychodzący przez Wi-Fi podczas przełączenia awaryjnego nigdzie nie trafia.

# /etc/pf.anchors/plex.forward
rdr pass on tun0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400
rdr pass on en0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400

Plik kotwicy sam nic nie robi; główna konfiguracja musi się do niego odwołać i go załadować. Umieść te dwie linie w /etc/pf.conf przed wszelkimi istniejącymi regułami przekierowania, następnie przeładuj i odczytaj, co jądro rzeczywiście przyjęło.

rdr-anchor "plex"
load anchor "plex" from "/etc/pf.anchors/plex.forward"

sudo pfctl -vnf /etc/pf.anchors/plex.forward
sudo pfctl -f /etc/pf.conf
sudo pfctl -s nat

Skarga na składnię dotyczącą nieznanego portu oznacza, że w twojej edycji przetrwał symbol zastępczy. Pusta tabela nat oznacza, że kotwica nigdy się nie załadowała, a ponieważ pf nie jest domyślnie włączony w obecnym macOS, sudo pfctl -E należy do poprawki, a nie do opcjonalnych dodatków. Przeładowuj kotwicę po każdym restarcie i po każdej zmianie mapowania. Trzymaj plik kotwicy pod kontrolą wersji, aby zmiana portu u dostawcy stała się edycją jednej linii, a nie nowym odkryciem.

Trzecie ogniwo: przypnij ten sam port wewnątrz Plex

W Plex otwórz Ustawienia, potem Serwer, potem Zdalny dostęp, i zaznacz pole, które pozwala ręcznie podać port. Wpisz zewnętrzny port dostawcy zamiast 32400, a następnie pozwól testowi osiągalności się uruchomić. Nowsze wersje przeniosły tę kontrolkę ze starszej strony Connect, więc zajrzyj pod Zdalny dostęp, jeśli pole nie jest tam, gdzie twierdzi poradnik.

Testowanie z sieci LAN nie dowodzi zupełnie niczego. Laptop w tej samej sieci Wi-Fi dociera do serwera bezpośrednio, więc próba udaje się nawet wtedy, gdy publiczna ścieżka jest martwa. Użyj telefonu z danymi komórkowymi albo dowolnego hosta spoza twojej sieci i wybierz stamtąd publiczny adres oraz port zewnętrzny.

Potwierdź każde ogniwo, zanim obwinisz Plex

Zacznij od odbiornika i pracuj na zewnątrz. Jeśli Plex jest związany tylko z adresem LAN, zignoruje przekierowanie skierowane na pętlę zwrotną, więc pierwsza komenda to ta, która dowodzi, gdzie nasłuchuje.

sudo lsof -nP -iTCP:32400 -sTCP:LISTEN

Następnie udowodnij, że przekierowanie istnieje i odpowiada portowi, który dałeś dostawcy. Tabela nat powinna pokazywać ten sam port zewnętrzny na obu interfejsach.

sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893

Uruchom tę ostatnią komendę spoza sieci, nie z Maca. Jeśli połączenie TCP kończy się z danych komórkowych, podczas gdy Plex nadal pokazuje niedostępność, port dociera do odbiornika, a pozostałym podejrzanym jest numer wpisany w pole Plex. Jeśli nic w ogóle nie odpowiada, przerwa jest wyżej: mapowanie u dostawcy, adres tunelu albo niewłączony pf.