Varför Plex fjärråtkomst misslyckas bakom ett VPN och hur du fixar det

Fjärråtkomst växlar till otillgänglig i samma ögonblick som ett VPN tar över standardrutten, medan samma server fortsätter att strömma till LAN utan klagomål. Inget i Plex-loggarna förklarar ändringen, eftersom Plex inte är delen som gick sönder: den publicerar en adress dit trafiken inte längre når. En leverantör som delar en offentlig adress mellan kunder vidarebefordrar en port till din tunneladress, och något på din egen maskin måste fortfarande flytta den porten till Plex-lyssnaren. Alla tre länkarna måste enas om en extern port innan tillgänglighetstestet blir grönt.

Kedjan har tre länkar, och Plex ser bara den sista

Leverantören äger en offentlig adress och mappar en av sina portar till din tunneladress. Din maskin tar allt som anländer på den porten och omdirigerar det till Plex-lyssnaren, som vanligtvis sitter på loopback-porten 32400. Sedan får Plex veta numret på den externa porten så att dess egen kontroll stämmer med det omvärlden slår.

Bryt en enda länk och webbgränssnittet rapporterar fjärråtkomst som otillgänglig, utan minsta antydan om vilken länk som fallerade. Den tystnaden är anledningen till att folk startar om servern, installerar om appen och slår av och på inställningen om och om igen utan att flytta nålen. De tre länkarna fallerar oberoende: en vidarebefordran riktad mot en inaktuell tunneladress, en omdirigering som bara täcker Ethernet-gränssnittet och ett Plex-fält som fortfarande håller 32400 ger alla samma röda text. Arbeta utåt från lyssnaren i stället för att gissa, och den felande länken namnger sig oftast inom en minut.

Första länken: vidarebefordra en port hos VPN-leverantören

Öppna leverantörens sida för portvidarebefordran och lägg till en mappning. De flesta implementeringar ger dig en slumpmässig extern port och låter dig välja den interna, så acceptera tilldelningen och rikta den mot tunneladressen som din klient har just nu. Skriv ner det numret, eftersom varje senare steg upprepar det exakt.

Leverantörer som roterar mappningen vid återanslutning är det vanliga skälet till att den här inställningen överlever en kväll och sedan dör. Vissa låter dig begära en stabil port, andra tilldelar en ny vid varje handskakning, så läs den aktuella mappningssidan innan du rör något annat.

Andra länken: omdirigera porten med ett pf-ankare

På macOS hör omdirigeringen till ett pf-ankare, en regel per gränssnitt som kan bära paketet. Skriv tunnelregeln först och Ethernet-regeln sedan, med samma externa port på båda, annars landar trafik som kommer in via Wi-Fi under en failover ingenstans.

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

Ankarfilen ensam gör ingenting; huvudkonfigurationen måste referera till den och ladda den. Sätt de här två raderna i /etc/pf.conf före alla befintliga omdirigeringsregler, ladda sedan om och läs tillbaka vad kärnan faktiskt accepterade.

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

Ett syntaxklagomål om en okänd port betyder att en platshållare överlevde din redigering. En tom nat-tabell betyder att ankaret aldrig laddades, och eftersom pf inte är aktiverat som standard på nuvarande macOS hör sudo pfctl -E till åtgärden och inte till de valfria tilläggen. Ladda om ankaret efter varje omstart och efter varje mappningsändring. Håll ankarfilen under versionskontroll så att en leverantörsportändring blir en redigering på en rad i stället för en ny upptäckt.

Tredje länken: fäst samma port inne i Plex

I Plex öppnar du Inställningar, sedan Server, sedan Fjärråtkomst, och kryssar i rutan som låter dig ange en port manuellt. Ange leverantörens externa port i stället för 32400 och låt sedan tillgänglighetstestet köra. Nyare versioner har flyttat den här kontrollen bort från den äldre Connect-sidan, så titta under Fjärråtkomst om fältet inte är där en guide påstår.

Att testa från LAN bevisar ingenting alls. En bärbar dator på samma Wi-Fi når servern direkt, så kontrollen lyckas även när den offentliga vägen är död. Använd en telefon med mobildata, eller vilken värd som helst utanför ditt nätverk, och slå den offentliga adressen och den externa porten därifrån.

Bekräfta varje länk innan du skyller på Plex

Börja vid lyssnaren och arbeta utåt. Om Plex bara är bundet till LAN-adressen ignorerar den en omdirigering riktad mot loopback, så det första kommandot är det som bevisar var den lyssnar.

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

Bevisa sedan att omdirigeringen finns och matchar porten du gav leverantören. nat-tabellen bör visa samma externa port på båda gränssnitten.

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

Kör det sista kommandot från utanför nätverket, inte från Macen. Om TCP-anslutningen fullbordas från mobildata medan Plex fortfarande visar otillgänglig, når porten lyssnaren och den kvarvarande misstänkta är numret som skrivits i Plex-fältet. Om ingenting svarar alls ligger brottet längre upp: leverantörens mappning, tunneladressen eller pf som inte är aktiverat.