Per què l'accés remot de Plex falla darrere d'una VPN i com arreglar-ho

L'accés remot passa a no disponible en el moment que una VPN pren la ruta per defecte, mentre el mateix servidor continua reproduint-se a la LAN sense queixes. Res als registres de Plex no explica el canvi, perquè Plex no és la part que s'ha trencat: publica una adreça on el trànsit ja no arriba. Un proveïdor que comparteix una adreça pública entre clients reenvia un port a l'adreça del teu túnel, i alguna cosa a la teva pròpia màquina encara ha de moure aquest port al receptor de Plex. Les tres baules han de coincidir en un sol port extern abans que la prova d'abastabilitat es posi verda.

La cadena té tres baules, i Plex només veu l'última

El proveïdor posseeix una adreça pública i assigna un dels seus ports a l'adreça del teu túnel. La teva màquina agafa tot el que arriba en aquest port i ho redirigeix al receptor de Plex, que normalment se situa al port de bucle 32400. Després es diu a Plex el número del port extern perquè la seva pròpia sonda coincideixi amb el que marca el món exterior.

Trenca qualsevol baula individual i la interfície web informa que l'accés remot no està disponible, sense cap indici de quina baula ha fallat. Aquest silenci és la raó per la qual la gent reinicia el servidor, reinstal·la l'aplicació i canvia el paràmetre una vegada i una altra sense moure l'agulla. Les tres baules fallen de manera independent: un reenviament dirigit a una adreça de túnel obsoleta, una redirecció que només cobreix la interfície Ethernet i un camp de Plex que encara conté 32400 produeixen el mateix text vermell. Treballa des del receptor cap enfora en lloc d'endevinar, i la baula que falla normalment es delata en un minut.

Primera baula: reenvia un port al proveïdor de VPN

Obre la pàgina de reenviament de ports del proveïdor i afegeix una assignació. La majoria d'implementacions et donen un port extern aleatori i et deixen triar l'intern, així que accepta l'assignació i apunta-la a l'adreça del túnel que el teu client té ara. Anota aquest número, perquè cada pas posterior el repeteix exactament.

Els proveïdors que roten l'assignació en reconnectar-se són la raó habitual que aquesta configuració aguanti una nit i després mori. Alguns et deixen demanar un port estable, altres reassignen un port a cada encaixada de mans, així que llegeix la pàgina d'assignació actual abans de tocar res més.

Segona baula: redirigeix el port amb una àncora pf

A macOS la redirecció pertany a una àncora pf, una regla per interfície que pugui portar el paquet. Escriu la regla del túnel primer i la regla Ethernet després, amb el mateix port extern a totes dues, o el trànsit que arriba per Wi-Fi durant un failover no anirà enlloc.

# /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 fitxer d'àncora per si sol no fa res; la configuració principal ha de referenciar-lo i carregar-lo. Posa aquestes dues línies a /etc/pf.conf abans de qualsevol regla de redirecció existent, després recarrega i torna a llegir què ha acceptat realment el nucli.

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 queixa de sintaxi sobre un port desconegut vol dir que un marcador de posició ha sobreviscut a la teva edició. Una taula nat buida vol dir que l'àncora no s'ha carregat mai, i com que pf no està activat per defecte a macOS actual, sudo pfctl -E forma part de la solució i no dels extres opcionals. Recarrega l'àncora després de cada reinici i de cada canvi d'assignació. Mantén el fitxer d'àncora sota control de versions perquè un canvi de port del proveïdor sigui una edició d'una línia i no un exercici de redescobriment.

Tercera baula: fixa el mateix port dins de Plex

A Plex, obre Configuració, després Servidor, després Accés remot, i marca la casella que et deixa especificar un port a mà. Introdueix el port extern del proveïdor en lloc de 32400, i deixa que s'executi la prova d'abastabilitat. Les versions més noves han mogut aquest control de la pàgina Connect antiga, així que mira sota Accés remot si el camp no és on una guia diu que és.

Provar des de la LAN no demostra absolutament res. Un portàtil a la mateixa Wi-Fi arriba al servidor directament, així que la sonda té èxit fins i tot mentre el camí públic és mort. Fes servir un telèfon amb dades mòbils, o qualsevol host fora de la teva xarxa, i marca l'adreça pública i el port extern des d'allà.

Confirma cada baula abans de culpar Plex

Comença pel receptor i treballa cap enfora. Si Plex només està lligat a l'adreça de la LAN, ignorarà una redirecció dirigida al bucle, així que la primera ordre és la que demostra on escolta.

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

Després, demostra que la redirecció existeix i coincideix amb el port que has donat al proveïdor. La taula nat hauria de mostrar el mateix port extern a les dues interfícies.

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

Executa aquesta última ordre des de fora de la xarxa, no des del Mac. Si la connexió TCP es completa des de dades mòbils mentre Plex encara mostra no disponible, el port arriba al receptor i el sospitós restant és el número escrit al camp de Plex. Si no respon res de res, la ruptura és més amunt: l'assignació del proveïdor, l'adreça del túnel o pf que no està activat.