Por qué el acceso remoto de Plex falla detrás de una VPN y cómo arreglarlo

El acceso remoto pasa a no disponible en el momento en que una VPN toma la ruta predeterminada, mientras el mismo servidor sigue transmitiendo a la LAN sin quejarse. Nada en los registros de Plex explica el cambio, porque Plex no es la parte que se rompió: publica una dirección donde el tráfico ya no aterriza. Un proveedor que comparte una dirección pública entre clientes reenvía un puerto a la dirección de tu túnel, y algo en tu propia máquina todavía tiene que mover ese puerto al receptor de Plex. Los tres eslabones deben ponerse de acuerdo en un mismo puerto externo antes de que la prueba de alcanzabilidad se ponga verde.

La cadena tiene tres eslabones, y Plex solo ve el último

El proveedor posee una dirección pública y asigna uno de sus puertos a la dirección de tu túnel. Tu máquina toma lo que llegue en ese puerto y lo redirige al receptor de Plex, que normalmente se sienta en el puerto de bucle 32400. Luego se le dice a Plex el número del puerto externo para que su propia sonda coincida con lo que marca el mundo exterior.

Rompe cualquier eslabón y la interfaz web informa que el acceso remoto no está disponible, sin ninguna pista de cuál falló. Ese silencio es la razón por la que la gente reinicia el servidor, reinstala la aplicación y alterna el ajuste una y otra vez sin mover la aguja. Los tres eslabones fallan de forma independiente: un reenvío dirigido a una dirección de túnel obsoleta, una redirección que solo cubre la interfaz Ethernet y un campo de Plex que todavía guarda 32400 producen el mismo texto rojo. Trabaja desde el receptor hacia afuera en lugar de adivinar, y el eslabón averiado suele nombrarse a sí mismo en un minuto.

Eslabón uno: reenvía un puerto en el proveedor de VPN

Abre la página de reenvío de puertos del proveedor y añade una asignación. La mayoría de las implementaciones te dan un puerto externo aleatorio y te dejan elegir el interno, así que acepta la asignación y apúntala a la dirección del túnel que tu cliente tiene ahora. Anota ese número, porque cada paso posterior lo repite exactamente.

Los proveedores que rotan la asignación al reconectar son la razón habitual de que esta configuración sobreviva una noche y luego muera. Algunos te dejan pedir un puerto estable, otros reasignan uno en cada apretón de manos, así que lee la página de asignación actual antes de tocar cualquier otra cosa.

Eslabón dos: redirige el puerto con un ancla pf

En macOS la redirección pertenece a un ancla pf, una regla por interfaz que pueda llevar el paquete. Escribe la regla del túnel primero y la regla Ethernet después, con el mismo puerto externo en ambas, o el tráfico que llega por Wi-Fi durante una conmutación por error no aterrizará 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

El archivo de ancla por sí solo no hace nada; la configuración principal tiene que referenciarlo y cargarlo. Pon estas dos líneas en /etc/pf.conf antes de cualquier regla de redirección existente, luego recarga y vuelve a leer qué aceptó realmente el 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

Una queja de sintaxis sobre un puerto desconocido significa que un marcador de posición sobrevivió a tu edición. Una tabla nat vacía significa que el ancla nunca se cargó, y como pf no está activado por defecto en macOS actual, sudo pfctl -E forma parte de la solución y no de los extras opcionales. Recarga el ancla después de cada reinicio y de cada cambio de asignación. Mantén el archivo de ancla bajo control de versiones para que un cambio de puerto del proveedor sea una edición de una línea y no un ejercicio de redescubrimiento.

Eslabón tres: fija el mismo puerto dentro de Plex

En Plex, abre Ajustes, luego Servidor, luego Acceso remoto, y marca la casilla que te permite especificar un puerto a mano. Introduce el puerto externo del proveedor en lugar de 32400, y deja que se ejecute la prueba de alcanzabilidad. Las compilaciones más nuevas movieron este control de la página Connect antigua, así que mira bajo Acceso remoto si el campo no está donde una guía afirma.

Probar desde la LAN no demuestra absolutamente nada. Un portátil en la misma Wi-Fi llega al servidor directamente, así que la sonda tiene éxito incluso mientras la ruta pública está muerta. Usa un teléfono con datos móviles, o cualquier host fuera de tu red, y marca la dirección pública y el puerto externo desde allí.

Confirma cada eslabón antes de culpar a Plex

Empieza por el receptor y trabaja hacia afuera. Si Plex solo está ligado a la dirección de la LAN, ignorará una redirección dirigida al bucle, así que el primer comando es el que demuestra dónde escucha.

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

Después, demuestra que la redirección existe y coincide con el puerto que le diste al proveedor. La tabla nat debería mostrar el mismo puerto externo en ambas interfaces.

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

Ejecuta ese último comando desde fuera de la red, no desde el Mac. Si la conexión TCP se completa desde datos móviles mientras Plex sigue mostrando no disponible, el puerto está llegando al receptor y el sospechoso restante es el número escrito en el campo de Plex. Si no responde nada en absoluto, la rotura está más arriba: la asignación del proveedor, la dirección del túnel o pf sin activar.