Como é que o Plex gere a autenticação entre sessões locais e remotas?

A autenticação do Plex utiliza a identidade do servidor e da conta como camada de confiança, enquanto as sessões locais e remotas diferem sobretudo na forma como chegam a esse servidor.

Um cliente local não é automaticamente anónimo, e um cliente remoto não fica autenticado apenas porque uma porta está acessível. Um servidor Plex associado a uma conta espera normalmente acesso autenticado; depois, as definições de ligação segura, a deteção de rede, a acessibilidade remota e quaisquer exceções à rede local definem o percurso. Compreender estas camadas evita confundir um problema de rede com um problema de conta.

Um servidor associado a uma conta utiliza a identidade da conta Plex como camada de confiança predefinida

A primeira fronteira é saber se o Plex Media Server está associado a uma conta ou iniciou sessão numa conta Plex. Quando essa relação existe, os clientes autenticam-se normalmente no servidor através do modelo de conta Plex, em vez de obterem acesso apenas por conseguirem alcançar a porta do serviço.

Os servidores associados a uma conta exigem autenticação por predefinição. Esta predefinição aplica-se à decisão de confiança; não significa que todas as ligações locais e remotas sigam o mesmo percurso de deteção ou encaminhamento.

Mantenha a identidade da conta separada das permissões da biblioteca. O Plex Home e os utilizadores geridos aplicam acesso e permissões específicos de cada utilizador, por isso, “o início de sessão funcionou” não equivale a “este utilizador consegue ver todas as bibliotecas”.

As sessões locais podem estar próximas sem serem anónimas

Na mesma rede doméstica, os clientes conseguem muitas vezes detetar e alcançar o servidor com menos etapas de encaminhamento, mas a aplicação continua a avaliar a identidade e as definições de segurança do servidor. A proximidade altera o percurso, não a ideia fundamental de que o servidor deve saber qual é o cliente autorizado a utilizá-lo.

O Plex disponibiliza definições de rede que podem permitir acesso local sem autenticação, mas estas exceções alargam deliberadamente a fronteira de confiança. Devem ser limitadas de forma rigorosa e não devem ser consideradas a resposta normal a um problema de autenticação.

Se um cliente local falhar enquanto os restantes funcionam, confirme o estado do início de sessão, o suporte da aplicação e o segmento de rede exato antes de alterar as regras de autenticação. Um problema de deteção entre VLAN ou numa rede Wi-Fi de convidados pode parecer uma falha de conta, mesmo quando as credenciais são válidas.

As ligações seguras protegem o percurso da sessão

A autenticação responde à questão de quem pode utilizar o servidor; uma ligação segura protege o tráfego que circula entre o cliente e o servidor. Estas são camadas relacionadas, mas diferentes, razão pela qual uma conta válida pode continuar a ter problemas de ligação se o cliente não conseguir negociar o percurso seguro esperado.

O Plex pode utilizar ligações seguras ao servidor, e a política de ligação deve ser testada com os clientes que realmente precisam de acesso. Os clientes mais antigos ou invulgares podem suportar o percurso seguro de forma diferente, por isso, não enfraqueça a política globalmente antes de identificar qual é o terminal que está a falhar.

Quando um cliente chega ao servidor de forma segura, a autenticação e a proteção do transporte funcionam em conjunto: o cliente comprova a sua identidade, o servidor aplica o acesso e a ligação protege a troca de dados. Uma falha em qualquer uma destas camadas pode produzir uma experiência semelhante de “servidor indisponível”.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

As sessões remotas acrescentam a deteção e a acessibilidade na fronteira da Internet

Uma sessão remota tem primeiro de alcançar o servidor doméstico através da fronteira da Internet. O mapeamento de portas, o NAT, as políticas da firewall, os túneis ou outros métodos de acesso remoto determinam se o percurso existe antes de a autenticação da conta poder ser concluída no servidor de destino.

O Acesso Remoto do Plex exige que o servidor tenha iniciado sessão e, em seguida, estabelece acessibilidade a partir do exterior da rede local. O mapeamento de portas, o NAT e as condições da firewall determinam se o percurso existe, enquanto a conta Plex e as permissões da biblioteca continuam a ser uma camada de confiança separada, ao nível da aplicação.

Mantenha a acessibilidade e a autenticação separadas durante o diagnóstico. Um percurso remoto pode falhar antes de a conta ser avaliada, e um servidor acessível pode continuar a negar acesso a um utilizador que não tenha iniciado sessão ou que não tenha acesso à biblioteca solicitada.

Os problemas locais e remotos devem ser testados como camadas separadas

Comece por utilizar uma conta conhecida e verifique primeiro o acesso local; em seguida, teste a mesma conta a partir de uma ligação verdadeiramente externa. Se a autenticação local funcionar, mas o acesso remoto falhar, investigue o percurso da Internet e a acessibilidade do servidor antes de repor contas ou alterar as permissões das bibliotecas.

A acessibilidade remota deve preservar o acesso autenticado ao servidor pretendido. Não utilize um túnel ou serviço de encaminhamento para contornar um problema de identidade ou permissões ainda não resolvido dentro do Plex.

Após uma mudança de router ou de rede, a linha de base da rede Plex após a mudança ajuda a separar o endereço, a deteção, a acessibilidade remota e a identidade do serviço. A autenticação torna-se mais fácil de compreender quando o percurso de rede é testado de forma independente, em vez de alterar várias definições de confiança ao mesmo tempo.