Por que o acesso remoto do Plex falha atrás de uma VPN e como corrigir

O acesso remoto passa a indisponível no momento em que uma VPN assume a rota padrão, enquanto o mesmo servidor continua a transmitir para a LAN sem reclamar. Nada nos registos do Plex explica a mudança, porque o Plex não é a parte que avariou: publica um endereço onde o tráfego já não chega. Um provedor que partilha um endereço público entre clientes encaminha uma porta para o endereço do seu túnel, e algo na sua própria máquina ainda tem de mover essa porta para o ouvinte do Plex. As três ligações têm de concordar numa mesma porta externa antes de o teste de alcance ficar verde.

A cadeia tem três ligações, e o Plex só vê a última

O provedor possui um endereço público e mapeia uma das suas portas para o endereço do seu túnel. A sua máquina pega em tudo o que chega a essa porta e redireciona-o para o ouvinte do Plex, que normalmente fica na porta de loopback 32400. Depois o Plex é informado do número da porta externa para que a sua própria sonda corresponda ao que o mundo exterior marca.

Quebre uma única ligação e a interface web reporta o acesso remoto como indisponível, sem qualquer indício de qual ligação falhou. Esse silêncio é a razão pela qual as pessoas reiniciam o servidor, reinstalam a aplicação e alternam a definição vezes sem conta sem mexer na agulha. As três ligações falham de forma independente: um encaminhamento apontado a um endereço de túnel desatualizado, um redirecionamento que só cobre a interface Ethernet e um campo do Plex que ainda contém 32400 produzem o mesmo texto vermelho. Trabalhe do ouvinte para fora em vez de adivinhar, e a ligação avariada normalmente identifica-se num minuto.

Primeira ligação: encaminhe uma porta no provedor de VPN

Abra a página de encaminhamento de portas do provedor e adicione um mapeamento. A maioria das implementações dá-lhe uma porta externa aleatória e deixa-o escolher a interna, por isso aceite a atribuição e aponte-a ao endereço do túnel que o seu cliente tem neste momento. Anote esse número, porque cada passo seguinte repete-o exatamente.

Os provedores que rodam o mapeamento ao reconectar são a razão habitual de esta configuração sobreviver uma noite e depois morrer. Alguns deixam-no pedir uma porta estável, outros reatribuem uma nova a cada handshake, por isso leia a página de mapeamento atual antes de tocar em qualquer outra coisa.

Segunda ligação: redirecione a porta com uma âncora pf

No macOS o redirecionamento pertence a uma âncora pf, uma regra por interface que consiga transportar o pacote. Escreva a regra do túnel primeiro e a regra Ethernet depois, com a mesma porta externa em ambas, caso contrário o tráfego que chega por Wi-Fi durante uma comutação por falha não aterra em lado nenhum.

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

O ficheiro da âncora sozinho não faz nada; a configuração principal tem de o referenciar e carregar. Coloque estas duas linhas em /etc/pf.conf antes de quaisquer regras de redirecionamento existentes, depois recarregue e releia o que o kernel aceitou realmente.

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

Uma queixa de sintaxe sobre uma porta desconhecida significa que um marcador de posição sobreviveu à sua edição. Uma tabela nat vazia significa que a âncora nunca foi carregada, e como o pf não está ativado por omissão no macOS atual, sudo pfctl -E faz parte da correção e não dos extras opcionais. Recarregue a âncora após cada reinício e após cada alteração de mapeamento. Mantenha o ficheiro da âncora sob controlo de versões para que uma alteração de porta no provedor passe a ser uma edição de uma linha e não um exercício de redescoberta.

Terceira ligação: fixe a mesma porta dentro do Plex

No Plex, abra Definições, depois Servidor, depois Acesso Remoto, e marque a caixa que lhe permite especificar uma porta à mão. Introduza a porta externa do provedor em vez de 32400, e depois deixe o teste de alcance correr. As compilações mais recentes moveram este controlo da página Connect antiga, por isso procure em Acesso Remoto se o campo não estiver onde um guia afirma.

Testar a partir da LAN não prova absolutamente nada. Um portátil na mesma Wi-Fi chega ao servidor diretamente, por isso a sonda tem sucesso mesmo enquanto o caminho público está morto. Use um telefone com dados móveis, ou qualquer anfitrião fora da sua rede, e marque o endereço público e a porta externa a partir daí.

Confirme cada ligação antes de culpar o Plex

Comece pelo ouvinte e trabalhe para fora. Se o Plex estiver ligado apenas ao endereço da LAN, ignorará um redirecionamento apontado ao loopback, por isso o primeiro comando é o que prova onde ele escuta.

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

De seguida, prove que o redirecionamento existe e corresponde à porta que entregou ao provedor. A tabela nat deve mostrar a mesma porta externa nas duas interfaces.

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

Execute esse último comando de fora da rede, não do Mac. Se a ligação TCP se completar a partir de dados móveis enquanto o Plex continua a mostrar indisponível, a porta está a chegar ao ouvinte e o suspeito restante é o número escrito no campo do Plex. Se nada responder de todo, a rutura está mais acima: o mapeamento do provedor, o endereço do túnel ou o pf não ativado.