Warum der Plex-Fernzugriff hinter einem VPN scheitert und wie man ihn repariert

Der Fernzugriff springt auf nicht verfügbar, sobald ein VPN die Standardroute übernimmt, während derselbe Server weiterhin ohne Murren ins LAN streamt. Nichts in den Plex-Protokollen erklärt die Änderung, denn Plex ist nicht der Teil, der kaputtging: Es veröffentlicht eine Adresse, an der der Verkehr nicht mehr ankommt. Ein Anbieter, der eine öffentliche Adresse unter Kunden teilt, leitet einen Port auf deine Tunneladresse weiter, und irgendetwas auf deinem eigenen Rechner muss diesen Port noch an den Plex-Listener weiterreichen. Alle drei Glieder müssen sich auf einen externen Port einigen, bevor der Erreichbarkeitstest grün wird.

Die Kette hat drei Glieder, und Plex sieht nur das letzte

Der Anbieter besitzt eine öffentliche Adresse und bildet einen seiner Ports auf deine Tunneladresse ab. Dein Rechner nimmt, was auf diesem Port ankommt, und leitet es an den Plex-Listener weiter, der normalerweise auf Loopback-Port 32400 sitzt. Dann wird Plex die Nummer des externen Ports mitgeteilt, damit seine eigene Prüfung zu dem passt, was die Außenwelt wählt.

Bricht ein einziges Glied, und die Weboberfläche meldet den Fernzugriff als nicht verfügbar, ohne einen Hinweis darauf, welches Glied versagt hat. Diese Stille ist der Grund, warum Leute den Server neu starten, die App neu installieren und die Einstellung immer wieder umschalten, ohne den Zeiger zu bewegen. Die drei Glieder versagen unabhängig voneinander: eine Weiterleitung auf eine veraltete Tunneladresse, eine Umleitung, die nur die Ethernet-Schnittstelle abdeckt, und ein Plex-Feld, das noch 32400 hält, erzeugen denselben roten Text. Arbeite dich vom Listener nach außen, statt zu raten, und das fehlerhafte Glied benennt sich meist innerhalb einer Minute selbst.

Glied eins: Leite einen Port beim VPN-Anbieter weiter

Öffne die Portweiterleitungsseite des Anbieters und füge eine Zuordnung hinzu. Die meisten Implementierungen geben dir einen zufälligen externen Port und lassen dich den internen wählen, also nimm die Zuweisung an und richte sie auf die Tunneladresse, die dein Client gerade hält. Schreib diese Nummer auf, denn jeder spätere Schritt wiederholt sie exakt.

Anbieter, die die Zuordnung beim Neuverbinden rotieren, sind der übliche Grund, warum dieses Setup einen Abend überlebt und dann stirbt. Manche lassen dich einen stabilen Port beantragen, andere vergeben bei jedem Handshake einen neuen, also lies die aktuelle Zuordnungsseite, bevor du irgendetwas anderes anfasst.

Glied zwei: Leite den Port mit einem pf-Anker um

Unter macOS gehört die Umleitung in einen pf-Anker, eine Regel pro Schnittstelle, die das Paket tragen kann. Schreib die Tunnelregel zuerst und die Ethernet-Regel danach, mit demselben externen Port auf beiden, sonst landet Verkehr, der während eines Failovers über WLAN ankommt, nirgendwo.

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

Die Ankerdatei allein bewirkt nichts; die Hauptkonfiguration muss sie referenzieren und laden. Setz diese beiden Zeilen in /etc/pf.conf vor alle vorhandenen Umleitungsregeln, lade dann neu und lies zurück, was der Kernel tatsächlich akzeptiert hat.

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

Eine Syntaxbeschwerde über einen unbekannten Port bedeutet, dass ein Platzhalter deine Bearbeitung überlebt hat. Eine leere nat-Tabelle bedeutet, dass der Anker nie geladen wurde, und da pf unter aktuellem macOS nicht standardmäßig aktiviert ist, gehört sudo pfctl -E zur Reparatur und nicht zum optionalen Beiwerk. Lade den Anker nach jedem Neustart und nach jeder Änderung der Zuordnung neu. Halt die Ankerdatei unter Versionskontrolle, damit eine Portänderung beim Anbieter zu einer Einzeiler-Bearbeitung wird statt zu einer neuen Entdeckungsreise.

Glied drei: Fixiere denselben Port in Plex

Öffne in Plex Einstellungen, dann Server, dann Fernzugriff, und setz das Häkchen im Kästchen, das dich einen Port von Hand angeben lässt. Trag den externen Port des Anbieters statt 32400 ein und lass dann den Erreichbarkeitstest laufen. Neuere Builds haben dieses Steuerelement von der älteren Connect-Seite wegbewegt, also schau unter Fernzugriff nach, wenn das Feld nicht dort ist, wo eine Anleitung behauptet.

Ein Test aus dem LAN beweist überhaupt nichts. Ein Laptop im selben WLAN erreicht den Server direkt, also gelingt die Prüfung selbst dann, wenn der öffentliche Weg tot ist. Nimm ein Handy mit Mobilfunkdaten oder einen beliebigen Host außerhalb deines Netzwerks und wähl die öffentliche Adresse und den externen Port von dort.

Bestätige jedes Glied, bevor du Plex die Schuld gibst

Fang beim Listener an und arbeite dich nach außen. Wenn Plex nur an die LAN-Adresse gebunden ist, ignoriert es eine Umleitung auf Loopback, also ist der erste Befehl der, der beweist, wo es lauscht.

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

Beweise als Nächstes, dass die Umleitung existiert und zu dem Port passt, den du dem Anbieter gegeben hast. Die nat-Tabelle sollte denselben externen Port auf beiden Schnittstellen zeigen.

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

Führ den letzten Befehl von außerhalb des Netzwerks aus, nicht vom Mac. Wenn die TCP-Verbindung über Mobilfunk zustande kommt, während Plex weiterhin nicht verfügbar zeigt, erreicht der Port den Listener, und der verbleibende Verdächtige ist die Zahl im Plex-Feld. Wenn gar nichts antwortet, liegt der Bruch weiter oben: die Zuordnung beim Anbieter, die Tunneladresse oder ein nicht aktiviertes pf.