Jak Plex obsługuje uwierzytelnianie w sesjach lokalnych i zdalnych?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Does Plex Handle Authentication Across Local and Remote Sessions? - Zima Store Online

Uwierzytelnianie Plex wykorzystuje tożsamość serwera i konta jako warstwę zaufania, a sesje lokalne i zdalne różnią się głównie sposobem łączenia się z tym serwerem.

Klient lokalny nie jest automatycznie anonimowy, a klient zdalny nie jest uwierzytelniony tylko dlatego, że port jest osiągalny. Zgłoszony serwer Plex zwykle oczekuje uwierzytelnionego dostępu, a ustawienia bezpiecznego połączenia, wykrywanie sieci, dostępność zdalna i ewentualne wyjątki dla sieci lokalnej wpływają na przebieg połączenia. Zrozumienie tych warstw pozwala uniknąć pomylenia problemu z siecią z problemem z kontem.

Zgłoszony serwer domyślnie wykorzystuje tożsamość konta Plex jako warstwę zaufania

Pierwsza granica dotyczy tego, czy Plex Media Server został zgłoszony do konta Plex lub jest do niego zalogowany. Po ustanowieniu tej relacji klienci zwykle uwierzytelniają się na serwerze za pośrednictwem modelu kont Plex, a nie uzyskują dostępu wyłącznie dlatego, że mogą połączyć się z portem usługi.

Zgłoszone serwery domyślnie wymagają uwierzytelniania. To ustawienie dotyczy decyzji o zaufaniu; nie oznacza, że każde połączenie lokalne i zdalne korzysta z tej samej ścieżki wykrywania lub routingu.

Tożsamość konta należy oddzielić od uprawnień do bibliotek. Plex Home i użytkownicy zarządzani stosują dostęp i uprawnienia przypisane do użytkownika, dlatego „logowanie się powiodło” nie oznacza tego samego co „ten użytkownik widzi każdą bibliotekę”.

Sesje lokalne mogą odbywać się w pobliżu, ale nie są anonimowe

W tej samej sieci domowej klienci często mogą wykryć serwer i połączyć się z nim przy użyciu mniejszej liczby etapów routingu, ale aplikacja nadal sprawdza tożsamość i ustawienia zabezpieczeń serwera. Lokalizacja zmienia ścieżkę, a nie podstawową zasadę, zgodnie z którą serwer powinien wiedzieć, który klient może z niego korzystać.

Plex oferuje ustawienia sieciowe, które mogą zapewnić lokalny dostęp bez uwierzytelniania, ale takie wyjątki celowo poszerzają granicę zaufania. Należy je ograniczać do niezbędnego zakresu i nie traktować jako standardowego rozwiązania problemu z uwierzytelnianiem.

Jeśli jeden klient lokalny nie działa, podczas gdy pozostałe działają, przed zmianą reguł uwierzytelniania sprawdź stan logowania, obsługę aplikacji i dokładny segment sieci. Problem z wykrywaniem między sieciami VLAN lub w sieci Wi-Fi dla gości może wyglądać jak awaria konta, nawet gdy dane logowania są prawidłowe.

Bezpieczne połączenia chronią ścieżkę sesji

Uwierzytelnianie odpowiada na pytanie, kto może korzystać z serwera, natomiast bezpieczne połączenie chroni dane przesyłane między klientem a serwerem. Są to powiązane, ale różne warstwy, dlatego prawidłowe konto może nadal napotkać problem z połączeniem, jeśli klient nie potrafi wynegocjować oczekiwanej bezpiecznej ścieżki.

Plex może korzystać z bezpiecznych połączeń z serwerem, a zasady połączeń należy testować na klientach, które rzeczywiście wymagają dostępu. Starsze lub nietypowe klienty mogą obsługiwać bezpieczną ścieżkę w inny sposób, dlatego przed zidentyfikowaniem wadliwego punktu końcowego nie należy globalnie osłabiać zasad.

Gdy klient łączy się z serwerem bezpiecznie, uwierzytelnianie i ochrona transmisji współdziałają: klient potwierdza tożsamość, serwer stosuje zasady dostępu, a połączenie chroni wymianę danych. Awaria dowolnej z tych warstw może powodować podobny komunikat „serwer niedostępny”.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Sesje zdalne wymagają dodatkowo wykrywania i dostępności na granicy internetu

Sesja zdalna musi najpierw dotrzeć do domowego serwera przez granicę internetu. Przekierowanie portów, NAT, reguły zapory, tunele lub inne rozwiązania dostępu zdalnego decydują o tym, czy ścieżka istnieje, zanim uwierzytelnianie konta będzie mogło zakończyć się na serwerze docelowym.

Usługa Plex Remote Access wymaga zalogowania serwera, a następnie zapewnia dostępność spoza sieci lokalnej. Przekierowanie portów, NAT i warunki zapory decydują o tym, czy ścieżka istnieje, natomiast konto Plex i uprawnienia do bibliotek pozostają oddzielną warstwą zaufania na poziomie aplikacji.

Podczas diagnozowania należy oddzielić dostępność od uwierzytelniania. Zdalna ścieżka może zawieść, zanim konto zostanie sprawdzone, a osiągalny serwer nadal może odrzucić użytkownika, który nie jest zalogowany lub nie ma dostępu do żądanej biblioteki.

Problemy lokalne i zdalne należy testować jako oddzielne warstwy

Rozpocznij od jednego znanego konta i najpierw zweryfikuj dostęp lokalny, a następnie przetestuj to samo konto z rzeczywiście zewnętrznego połączenia. Jeśli uwierzytelnianie lokalne działa, ale dostęp zdalny nie, przed resetowaniem kont lub zmianą uprawnień bibliotek sprawdź ścieżkę internetową i dostępność serwera.

Dostęp zdalny powinien zachowywać uwierzytelniony dostęp do właściwego serwera. Nie używaj tunelu ani usługi przekierowywania, aby omijać nierozwiązany problem z tożsamością lub uprawnieniami w Plex.

Po zmianie routera lub sieci baza sieciowa Plex po przeprowadzce pomaga oddzielić adres, wykrywanie, dostępność zdalną i tożsamość usługi. Uwierzytelnianie łatwiej zrozumieć, gdy ścieżka sieciowa jest testowana niezależnie, zamiast jednocześnie zmieniać kilka ustawień zaufania.