Pourquoi l'accès à distance de Plex échoue derrière un VPN et comment le réparer

L'accès à distance bascule en indisponible à l'instant où un VPN prend la route par défaut, tandis que le même serveur continue de diffuser vers le LAN sans se plaindre. Rien dans les journaux de Plex n'explique ce changement, car Plex n'est pas la partie qui a cassé : il publie une adresse où le trafic n'arrive plus. Un fournisseur qui partage une adresse publique entre clients transfère un port vers l'adresse de votre tunnel, et quelque chose sur votre propre machine doit encore déplacer ce port vers l'écouteur Plex. Les trois maillons doivent s'accorder sur un même port externe avant que le test d'accessibilité passe au vert.

La chaîne a trois maillons, et Plex ne voit que le dernier

Le fournisseur possède une adresse publique et mappe l'un de ses ports vers l'adresse de votre tunnel. Votre machine prend tout ce qui arrive sur ce port et le redirige vers l'écouteur Plex, qui se trouve normalement sur le port de bouclage 32400. Plex est ensuite informé du numéro de port externe pour que sa propre sonde corresponde à ce que le monde extérieur compose.

Cassez un seul maillon et l'interface web signale l'accès à distance comme indisponible, sans le moindre indice sur le maillon défaillant. Ce silence explique pourquoi les gens redémarrent le serveur, réinstallent l'application et basculent le réglage encore et encore sans faire bouger l'aiguille. Les trois maillons échouent indépendamment : un transfert visant une adresse de tunnel périmée, une redirection qui ne couvre que l'interface Ethernet et un champ Plex contenant encore 32400 produisent tous le même texte rouge. Travaillez de l'écouteur vers l'extérieur plutôt que de deviner, et le maillon défaillant se nomme généralement en une minute.

Premier maillon : transférez un port chez le fournisseur VPN

Ouvrez la page de transfert de ports du fournisseur et ajoutez un mappage. La plupart des implémentations vous donnent un port externe aléatoire et vous laissent choisir l'interne, alors acceptez l'attribution et pointez-la vers l'adresse de tunnel que votre client détient actuellement. Notez ce numéro, car chaque étape suivante le répète exactement.

Les fournisseurs qui font tourner le mappage à la reconnexion sont la raison habituelle pour laquelle cette configuration survit une soirée puis meurt. Certains vous laissent demander un port stable, d'autres en réattribuent un à chaque poignée de main, alors lisez la page de mappage actuelle avant de toucher à quoi que ce soit d'autre.

Deuxième maillon : redirigez le port avec une ancre pf

Sur macOS, la redirection appartient à une ancre pf, une règle par interface capable de porter le paquet. Écrivez la règle du tunnel d'abord et la règle Ethernet ensuite, avec le même port externe sur les deux, sinon le trafic qui arrive en Wi-Fi pendant un basculement n'atterrit nulle part.

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

Le fichier d'ancre seul ne fait rien ; la configuration principale doit y faire référence et le charger. Placez ces deux lignes dans /etc/pf.conf avant toute règle de redirection existante, puis rechargez et relisez ce que le noyau a réellement accepté.

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

Une plainte de syntaxe à propos d'un port inconnu signifie qu'un espace réservé a survécu à votre modification. Une table nat vide signifie que l'ancre n'a jamais été chargée, et comme pf n'est pas activé par défaut sur macOS actuel, sudo pfctl -E fait partie du correctif et non des extras optionnels. Rechargez l'ancre après chaque redémarrage et après chaque changement de mappage. Gardez le fichier d'ancre sous contrôle de version pour qu'un changement de port chez le fournisseur devienne une modification d'une ligne plutôt qu'un exercice de redécouverte.

Troisième maillon : fixez le même port dans Plex

Dans Plex, ouvrez Réglages, puis Serveur, puis Accès à distance, et cochez la case qui vous permet de spécifier un port à la main. Saisissez le port externe du fournisseur plutôt que 32400, puis laissez le test d'accessibilité s'exécuter. Les versions plus récentes ont déplacé ce contrôle hors de l'ancienne page Connect, alors regardez sous Accès à distance si le champ n'est pas là où un guide prétend qu'il est.

Tester depuis le LAN ne prouve absolument rien. Un portable sur le même Wi-Fi atteint le serveur directement, donc la sonde réussit même lorsque le chemin public est mort. Utilisez un téléphone en données mobiles, ou n'importe quel hôte hors de votre réseau, et composez l'adresse publique et le port externe depuis là.

Confirmez chaque maillon avant de blâmer Plex

Commencez par l'écouteur et travaillez vers l'extérieur. Si Plex n'est lié qu'à l'adresse du LAN, il ignorera une redirection visant la boucle, donc la première commande est celle qui prouve où il écoute.

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

Ensuite, prouvez que la redirection existe et correspond au port que vous avez donné au fournisseur. La table nat devrait afficher le même port externe sur les deux interfaces.

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

Exécutez cette dernière commande depuis l'extérieur du réseau, pas depuis le Mac. Si la connexion TCP aboutit depuis les données mobiles alors que Plex affiche encore indisponible, le port atteint l'écouteur et le suspect restant est le numéro saisi dans le champ Plex. Si rien ne répond du tout, la rupture est en amont : le mappage du fournisseur, l'adresse du tunnel ou pf non activé.