Perché l'accesso remoto di Plex fallisce dietro una VPN e come risolverlo

L'accesso remoto passa a non disponibile nel momento in cui una VPN prende la rotta predefinita, mentre lo stesso server continua a trasmettere verso la LAN senza lamentarsi. Nulla nei registri di Plex spiega il cambiamento, perché Plex non è la parte che si è rotta: pubblica un indirizzo dove il traffico non arriva più. Un provider che condivide un indirizzo pubblico tra i clienti inoltra una porta verso l'indirizzo del tuo tunnel, e qualcosa sulla tua macchina deve ancora spostare quella porta verso l'ascoltatore di Plex. Tutti e tre gli anelli devono concordare una stessa porta esterna prima che il test di raggiungibilità diventi verde.

La catena ha tre anelli, e Plex vede solo l'ultimo

Il provider possiede un indirizzo pubblico e mappa una delle sue porte sull'indirizzo del tuo tunnel. La tua macchina prende ciò che arriva su quella porta e lo redirige verso l'ascoltatore di Plex, che di solito si trova sulla porta di loopback 32400. Poi a Plex viene detto il numero della porta esterna perché la sua sonda coincida con ciò che compone il mondo esterno.

Rompi un solo anello e l'interfaccia web segnala l'accesso remoto come non disponibile, senza alcun indizio su quale anello abbia ceduto. Quel silenzio è il motivo per cui le persone riavviano il server, reinstallano l'app e alternano l'impostazione più e più volte senza spostare l'ago. I tre anelli falliscono in modo indipendente: un inoltro puntato a un indirizzo di tunnel obsoleto, una redirezione che copre solo l'interfaccia Ethernet e un campo di Plex che contiene ancora 32400 producono tutti lo stesso testo rosso. Lavora dall'ascoltatore verso l'esterno invece di indovinare, e l'anello guasto di solito si nomina da solo entro un minuto.

Primo anello: inoltra una porta presso il provider VPN

Apri la pagina di inoltro porte del provider e aggiungi una mappatura. La maggior parte delle implementazioni ti dà una porta esterna casuale e ti lascia scegliere quella interna, quindi accetta l'assegnazione e puntala all'indirizzo del tunnel che il tuo client ha in questo momento. Annota quel numero, perché ogni passaggio successivo lo ripete esattamente.

I provider che ruotano la mappatura alla riconnessione sono il motivo abituale per cui questa configurazione sopravvive una sera e poi muore. Alcuni ti lasciano chiedere una porta stabile, altri ne riassegnano una a ogni stretta di mano, quindi leggi la pagina di mappatura attuale prima di toccare qualsiasi altra cosa.

Secondo anello: reindirizza la porta con un'ancora pf

Su macOS la redirezione appartiene a un'ancora pf, una regola per interfaccia in grado di portare il pacchetto. Scrivi prima la regola del tunnel e poi quella Ethernet, con la stessa porta esterna su entrambe, altrimenti il traffico che arriva via Wi-Fi durante un failover non approda da nessuna parte.

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

Il file dell'ancora da solo non fa nulla; la configurazione principale deve farvi riferimento e caricarlo. Metti queste due righe in /etc/pf.conf prima di qualsiasi regola di redirezione esistente, poi ricarica e rileggi ciò che il kernel ha effettivamente accettato.

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 lamentela di sintassi su una porta sconosciuta significa che un segnaposto è sopravvissuto alla tua modifica. Una tabella nat vuota significa che l'ancora non è mai stata caricata, e poiché pf non è attivo per impostazione predefinita sul macOS attuale, sudo pfctl -E fa parte della correzione e non degli extra opzionali. Ricarica l'ancora dopo ogni riavvio e dopo ogni modifica della mappatura. Tieni il file dell'ancora sotto controllo di versione così che una modifica della porta presso il provider diventi una modifica di una riga invece di un nuovo esercizio di scoperta.

Terzo anello: fissa la stessa porta dentro Plex

In Plex apri Impostazioni, poi Server, poi Accesso remoto, e spunta la casella che ti consente di specificare una porta a mano. Inserisci la porta esterna del provider invece di 32400, poi lascia girare il test di raggiungibilità. Le build più recenti hanno spostato questo controllo dalla vecchia pagina Connect, quindi guarda sotto Accesso remoto se il campo non è dove una guida sostiene.

Testare dalla LAN non dimostra assolutamente nulla. Un portatile sulla stessa Wi-Fi raggiunge il server direttamente, quindi la sonda riesce anche mentre il percorso pubblico è morto. Usa un telefono con dati cellulari, o qualsiasi host fuori dalla tua rete, e componi l'indirizzo pubblico e la porta esterna da lì.

Conferma ogni anello prima di dare la colpa a Plex

Parti dall'ascoltatore e lavora verso l'esterno. Se Plex è legato solo all'indirizzo della LAN ignorerà una redirezione puntata al loopback, quindi il primo comando è quello che dimostra dove ascolta.

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

Poi dimostra che la redirezione esiste e corrisponde alla porta che hai dato al provider. La tabella nat dovrebbe mostrare la stessa porta esterna su entrambe le interfacce.

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

Esegui quell'ultimo comando da fuori la rete, non dal Mac. Se la connessione TCP si completa dai dati cellulari mentre Plex mostra ancora non disponibile, la porta sta raggiungendo l'ascoltatore e il sospetto rimasto è il numero digitato nel campo di Plex. Se non risponde nulla, la rottura è a monte: la mappatura del provider, l'indirizzo del tunnel o pf non attivo.