Firwat de Plex-Fernzougrëff hannert engem VPN verseeit an wéi een dat reparéiert

De Fernzougrëff spréngt op net verfügbar, soubal e VPN d'Standardroute iwwerhëlt, wärend deeselwechte Server weider ouni Kloen an d'LAN streamt. Nichts an de Plex-Loggen erkläert d'Ännerung, well Plex net deen Deel ass, deen d'Been gebrach huet: et verëffentlecht eng Adress, wou den Trafik net méi ukommt. En Anbieter, deen eng ëffentlech Adress ënner Clienten deelt, leet ee Port op Är Tunneladress weider, an et muss nach ëmmer eppes op Ärem eegene Rechner dee Port un den Plex-Listener weiderginn. All dräi Glidder mussen sech op een externen Port eeneg ginn, ier den Erreechbarkeetstest gréng gëtt.

D'Kette huet dräi Glidder, an de Plex gesäit nëmmen dat lescht

Den Anbieter besëtzt eng ëffentlech Adress an hëlt ee vu senge Porten op Är Tunneladress of. Äre Rechner hëlt alles, wat op deem Port ukommt, an ëmleed et un den Plex-Listener, deen normalerweis op Loopback-Port 32400 sëtzt. Duerno gëtt dem Plex d'Nummer vum externen Port gesot, sou datt seng eege Prüfung mat deem iwwerenee stëmmt, wat d'Baussewelt wielt.

Briecht een eenzegt Glidd, an de Webinterface mellt de Fernzougrëff als net verfügbar, ouni en Hiwäis, wéi ee Glidd versot huet. Dës Stille ass de Grond, firwat d'Leit de Server nei starten, d'App nei installéieren an d'Astellung ëmmer erëm ëmschalten, ouni d'Nol ze réckelen. Déi dräi Glidder versoen onofhängeg: eng Weiderleitung op eng verouderte Tunneladress, eng Ëmleitung déi nëmmen d'Ethernet-Schnittstell deckt, an e Plex-Feld, dat nach 32400 hält, ginn all deeselwechte rouden Text. Schafft vum Listener no baussen amplaz ze roden, an dat schlëmmt Glidd nennt sech meeschtens bannent enger Minutt.

Glidd een: leet ee Port beim VPN-Anbieter weider

Maacht d'Port-Weiderleitungssäit vum Anbieter op a füügt eng Mapping derbäi. Déi meescht Implementéierungen ginn Iech en zoufällegen externen Port a loosse Iech den internen auswielen, also akzeptéiert d'Zoudeelung a riicht se op d'Tunneladress, déi Äre Client just hält. Schreift dës Nummer op, well all spéidere Schrëtt se genee widderhëlt.

Anbieter, déi d'Mapping bei der Neiverbindung roteren, sinn de gewéinleche Grond, firwat dës Konfiguratioun en Owend iwwerlieft an dann stierft. E puer loossen Iech en stabile Port ufroen, anerer deelen all Handshake en neien zou, also liest d'aktuell Mapping-Säit, ier Dir eppes anescht ugeschitt.

Glidd zwee: leet de Port mat engem pf-Anker ëm

Op macOS gehéiert d'Ëmleitung an e pf-Anker, eng Regel pro Schnittstell, déi de Paket droe kann. Schreift d'Tunnelregel fir d'éischt an d'Ethernet-Regel duerno, mam selwechten externen Port op béiden, soss landt Trafik, deen iwwer Wi-Fi während engem Failover ukommt, néiergendwo.

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

D'Ankerdatei eleng mécht näischt; d'Haaptkonfiguratioun muss drop referenzéieren an se lueden. Setzt dës zwou Zeilen an /etc/pf.conf virun all existéierend Ëmleitungsregelen, luet dann nei a liest zréck, wat de Kernel tatsächlech akzeptéiert huet.

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

Eng Syntaxbeschwerde iwwer en onbekannte Port bedeit, datt e Platzhalter Är Ännerung iwwerlieft huet. Eng eidel nat-Tabell bedeit, datt den Anker ni gelueden gouf, a well pf op aktuellem macOS net standardméisseg aktivéiert ass, gehéiert sudo pfctl -E zu der Reparatur an net zu den optionale Zousätz. Luet den Anker no all Neistart an no all Mapping-Ännerung nei. Hält d'Ankerdatei ënner Versiounskontroll, sou datt eng Port-Ännerung beim Anbieter eng Ännerung vun enger Zeil gëtt an net eng nei Entdeckungsrees.

Glidd dräi: fixéiert deeselwechte Port am Plex

Am Plex maacht Astellungen op, dann Server, dann Fernzougrëff, a klickt d'Këscht un, déi Iech erlaabt, e Port vun Hand ze bestëmmen. Gitt den externen Port vum Anbieter amplaz 32400 an, a loosst dann den Erreechbarkeetstest lafen. Méi nei Builden hunn dës Steierung vun der eelerer Connect-Säit fortgeréckelt, also kuckt ënner Fernzougrëff, wann d'Feld net do ass, wou eng Uleitung behaapt.

Testen aus der LAN beweet guer näischt. E Laptop am selwechte Wi-Fi erreecht de Server direkt, also geet d'Prüfung duerch, och wann de ëffentleche Wee dout ass. Benotzt en Telefon mat mobilen Daten oder en Host baussent Ärem Netz, a wielt d'ëffentlech Adress an den externen Port vun do aus.

Bestätegt all Glidd, ier Dir de Plex beschëllegt

Fänkt beim Listener un a schafft no baussen. Wann de Plex nëmmen un d'LAN-Adress gebonnen ass, ignoréiert en eng Ëmleitung op Loopback, also ass den éischte Befehl deen, dee beweist, wou en lauschtert.

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

Beweist duerno, datt d'Ëmleitung existéiert an zum Port passt, deen Dir dem Anbieter ginn hutt. D'nat-Tabell soll deeselwechten externen Port op béiden Schnittstelle weisen.

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

Féiert deen leschte Befehl vun ausserhalb vum Netz aus, net vum Mac. Wann d'TCP-Verbindung iwwer mobil Daten fäerdeg gëtt, wärend de Plex nach ëmmer net verfügbar weist, erreecht de Port den Listener an de verbleiwenen Verdächtegen ass d'Nummer, déi am Plex-Feld agetippt gouf. Wann iwwerhaapt näischt äntwert, ass de Broch uewen: d'Mapping vum Anbieter, d'Tunneladress oder de pf, deen net aktivéiert ass.