Waarom Plex-externe toegang achter een VPN mislukt en hoe je het oplost

Externe toegang springt op niet beschikbaar op het moment dat een VPN de standaardroute overneemt, terwijl dezelfde server zonder klagen naar de LAN blijft streamen. Niets in de Plex-logs verklaart de verandering, want Plex is niet het onderdeel dat kapotging: het publiceert een adres waar verkeer niet meer aankomt. Een provider die één openbaar adres tussen klanten deelt, stuurt een poort door naar je tunneladres, en iets op je eigen machine moet die poort nog steeds naar de Plex-listener verplaatsen. Alle drie schakels moeten het over één externe poort eens zijn voordat de bereikbaarheidstest groen wordt.

De keten heeft drie schakels, en Plex ziet alleen de laatste

De provider bezit een openbaar adres en mapt een van zijn poorten naar je tunneladres. Je machine neemt alles wat op die poort binnenkomt en leidt het door naar de Plex-listener, die meestal op loopback-poort 32400 zit. Daarna krijgt Plex het nummer van de externe poort te horen, zodat zijn eigen controle overeenkomt met wat de buitenwereld kiest.

Breek één schakel en de webinterface meldt externe toegang als niet beschikbaar, zonder enige aanwijzing welke schakel faalde. Die stilte is de reden dat mensen de server herstarten, de app opnieuw installeren en de instelling steeds weer omzetten zonder de naald te verplaatsen. De drie schakels falen onafhankelijk: een doorsturing naar een verouderd tunneladres, een omleiding die alleen de Ethernet-interface dekt, en een Plex-veld dat nog 32400 bevat leveren allemaal dezelfde rode tekst. Werk van de listener naar buiten in plaats van te gokken, en de falende schakel noemt zichzelf meestal binnen een minuut.

Schakel één: stuur een poort door bij de VPN-provider

Open de port forwarding-pagina van de provider en voeg een mapping toe. De meeste implementaties geven je een willekeurige externe poort en laten je de interne kiezen, dus accepteer de toewijzing en richt die op het tunneladres dat je client nu heeft. Schrijf dat nummer op, want elke latere stap herhaalt het precies.

Providers die de mapping bij herverbinden roteren zijn de gebruikelijke reden dat deze opzet een avond overleeft en dan sterft. Sommige laten je een stabiele poort aanvragen, andere wijzen bij elke handshake een nieuwe toe, dus lees de huidige mapping-pagina voordat je iets anders aanraakt.

Schakel twee: leid de poort om met een pf-anker

Op macOS hoort de omleiding in een pf-anker, één regel per interface die het pakket kan dragen. Schrijf de tunnelregel eerst en de Ethernet-regel daarna, met dezelfde externe poort op beide, anders landt verkeer dat tijdens een failover via Wi-Fi binnenkomt nergens.

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

Het ankerbestand alleen doet niets; de hoofdconfiguratie moet ernaar verwijzen en het laden. Zet deze twee regels in /etc/pf.conf vóór alle bestaande omleidingsregels, herlaad daarna en lees terug wat de kernel werkelijk accepteerde.

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

Een syntaxisfout over een onbekende poort betekent dat een plaatsaanduiding je bewerking heeft overleefd. Een lege nat-tabel betekent dat het anker nooit is geladen, en omdat pf op huidige macOS niet standaard is ingeschakeld, hoort sudo pfctl -E bij de oplossing en niet bij de optionele extra's. Herlaad het anker na elke herstart en na elke wijziging van de mapping. Houd het ankerbestand onder versiebeheer, zodat een poortwijziging bij de provider een bewerking van één regel wordt in plaats van een herontdekking.

Schakel drie: zet dezelfde poort vast in Plex

Open in Plex Instellingen, dan Server, dan Externe toegang, en vink het vakje aan waarmee je een poort handmatig kunt opgeven. Voer de externe poort van de provider in in plaats van 32400, en laat de bereikbaarheidstest lopen. Nieuwere builds hebben deze bediening weggehaald van de oudere Connect-pagina, dus kijk onder Externe toegang als het veld niet staat waar een handleiding beweert.

Testen vanaf de LAN bewijst helemaal niets. Een laptop op dezelfde Wi-Fi bereikt de server rechtstreeks, dus de controle slaagt zelfs terwijl het openbare pad dood is. Gebruik een telefoon met mobiele data, of een host buiten je netwerk, en kies daar het openbare adres en de externe poort.

Bevestig elke schakel voordat je Plex de schuld geeft

Begin bij de listener en werk naar buiten. Als Plex alleen aan het LAN-adres gebonden is, negeert het een omleiding naar loopback, dus het eerste commando is het commando dat bewijst waar het luistert.

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

Bewijs daarna dat de omleiding bestaat en overeenkomt met de poort die je de provider gaf. De nat-tabel hoort dezelfde externe poort op beide interfaces te tonen.

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

Voer dat laatste commando van buiten het netwerk uit, niet vanaf de Mac. Als de TCP-verbinding via mobiele data tot stand komt terwijl Plex nog niet beschikbaar toont, bereikt de poort de listener en is de resterende verdachte het nummer in het Plex-veld. Als er helemaal niets antwoordt, zit de breuk stroomopwaarts: de mapping bij de provider, het tunneladres of een niet-ingeschakelde pf.