Por que falla o acceso remoto de Plex detrás dunha VPN e como arranxalo
O acceso remoto de Plex detrás dunha VPN necesita tres elos: un reenvío de porto no provedor, unha redirección pf local e o mesmo porto externo escrito en Plex.
O acceso remoto pasa a non dispoñible no momento en que unha VPN toma a ruta predeterminada, mentres o mesmo servidor segue transmitindo á LAN sen queixarse. Nada nos rexistros de Plex explica o cambio, porque Plex non é a parte que se rompeu: publica un enderezo onde o tráfico xa non aterra. Un provedor que comparte un enderezo público entre clientes reenvía un porto ao enderezo do teu túnel, e algo na túa propia máquina aínda ten que mover ese porto ao receptor de Plex. Os tres elos deben poñerse de acordo nun mesmo porto externo antes de que a proba de alcanzabilidade se poña verde.
A cadea ten tres elos, e Plex só ve o último
O provedor posúe un enderezo público e asigna un dos seus portos ao enderezo do teu túnel. A túa máquina toma o que chegue nese porto e rediríxeo ao receptor de Plex, que normalmente se senta no porto de bucle 32400. Despois díselles a Plex o número do porto externo para que a súa propia sonda coincida co que marca o mundo exterior.
Rompe calquera elo individual e a interface web informa que o acceso remoto non está dispoñible, sen ningunha pista de cal fallou. Ese silencio é a razón pola que a xente reinicia o servidor, reinstala a aplicación e alterna o axuste unha e outra vez sen mover a agulla. Os tres elos fallan de forma independente: un reenvío dirixido a un enderezo de túnel obsoleto, unha redirección que só cobre a interface Ethernet e un campo de Plex que aínda garda 32400 producen o mesmo texto vermello. Traballa desde o receptor cara a fóra en lugar de adiviñar, e o elo avariado adoita nomearse a si mesmo nun minuto.
Primeiro elo: reenvía un porto no provedor de VPN
Abre a páxina de reenvío de portos do provedor e engade unha asignación. A maioría das implementacións danche un porto externo aleatorio e déixanche escoller o interno, así que acepta a asignación e apúntaa ao enderezo do túnel que o teu cliente ten agora. Anota ese número, porque cada paso posterior repíteo exactamente.
Os provedores que rotan a asignación ao reconectar son a razón habitual de que esta configuración sobreviva unha noite e logo morra. Algúns déixanche pedir un porto estable, outros reasignan un en cada aperto de mans, así que le a páxina de asignación actual antes de tocar calquera outra cousa.
Segundo elo: redirixe o porto cunha áncora pf
En macOS a redirección pertence a unha áncora pf, unha regra por interface que poida levar o paquete. Escribe a regra do túnel primeiro e a regra Ethernet despois, co mesmo porto externo nas dúas, ou o tráfico que chega por Wi-Fi durante unha conmutación por erro non aterrará en ningún sitio.
# /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 de áncora por si só non fai nada; a configuración principal ten que referencialo e cargalo. Pon estas dúas liñas en /etc/pf.conf antes de calquera regra de redirección existente, despois recarga e volve ler que aceptou realmente o núcleo.
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
Unha queixa de sintaxe sobre un porto descoñecido significa que un marcador de posición sobreviviu á túa edición. Unha táboa nat baleira significa que a áncora nunca se cargou, e como pf non está activado por defecto en macOS actual, sudo pfctl -E forma parte da solución e non dos extras opcionais. Recarga a áncora despois de cada reinicio e de cada cambio de asignación. Mantén o ficheiro de áncora baixo control de versións para que un cambio de porto do provedor sexa unha edición dunha liña e non un exercicio de redescubrimento.
Terceiro elo: fixa o mesmo porto dentro de Plex
En Plex, abre Axustes, logo Servidor, logo Acceso remoto, e marca a caixa que che permite especificar un porto a man. Introduce o porto externo do provedor en lugar de 32400, e deixa que se execute a proba de alcanzabilidade. As versións máis novas moveron este control da páxina Connect antiga, así que mira baixo Acceso remoto se o campo non está onde unha guía afirma.
Probar desde a LAN non demostra absolutamente nada. Un portátil na mesma Wi-Fi chega ao servidor directamente, así que a sonda ten éxito mesmo mentres a ruta pública está morta. Usa un teléfono con datos móbiles, ou calquera host fóra da túa rede, e marca o enderezo público e o porto externo desde alí.
Confirma cada elo antes de culpar a Plex
Comeza polo receptor e traballa cara a fóra. Se Plex só está ligado ao enderezo da LAN, ignorará unha redirección dirixida ao bucle, así que o primeiro comando é o que demostra onde escoita.
sudo lsof -nP -iTCP:32400 -sTCP:LISTEN
Despois, demostra que a redirección existe e coincide co porto que lle deches ao provedor. A táboa nat debería mostrar o mesmo porto externo nas dúas interfaces.
sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893
Executa ese último comando desde fóra da rede, non desde o Mac. Se a conexión TCP se completa desde datos móbiles mentres Plex aínda mostra non dispoñible, o porto está a chegar ao receptor e o sospeitoso restante é o número escrito no campo de Plex. Se non responde nada de nada, a rotura está máis arriba: a asignación do provedor, o enderezo do túnel ou pf sen activar.