Wêrom't Plex-ôfstânstagon efter in VPN mislearret en hoe't jo it oplosse

Ôfstânstagon slacht op net beskikber op it stuit dat in VPN de standertrûte oernimt, wylst deselde tsjinner sûnder klacht nei de LAN bliuwt streamen. Neat yn 'e Plex-logs ferklearret de feroaring, want Plex is net it part dat stikken gien is: it publisearret in adres dêr't ferkear net mear telâne komt. In provider dy't ien iepenbier adres tusken klanten dielt, stjoert in port nei jo tunneladres, en eat op jo eigen masine moat dy port noch altyd nei de Plex-harker ferpleatse. Alle trije skeakels moatte it oer ien eksterne port iens wêze foardat de berikberheidstest grien wurdt.

De keatling hat trije skeakels, en Plex sjocht allinnich de lêste

De provider hat in iepenbier adres en mappet ien fan syn ports nei jo tunneladres. Jo masine nimt alles wat op dy port oankomt en oerstjoert it nei de Plex-harker, dy't normaal op loopback-port 32400 sit. Dêrnei wurdt Plex it nûmer fan 'e eksterne port ferteld, sadat syn eigen probe oerienkomt mei wat de bûtenwrâld kiest.

Breek ien inkele skeakel en de webynterface meldt ôfstânstagon as net beskikber, sûnder in hint hokker skeakel mislearre. Dat stilswijen is de reden dat minsken de tsjinner opnij starte, de app opnij ynstallearje en de ynstelling oer en oer wer omsette sûnder de nulle te ferpleatsen. De trije skeakels mislearje ûnôfhinklik: in trochstjoering rjochte op in ferâldere tunneladres, in oerstjoering dy't allinnich de Ethernet-ynterface dekt, en in Plex-fjild dat noch 32400 hâldt, jouwe allegear deselde reade tekst. Wurket fan 'e harker nei bûten ta ynstee fan te rieden, en de mislearre skeakel neamt himsels meastentiids binnen in minút.

Skeakel ien: stjoer in port troch by de VPN-provider

Iepenje de port-forwarding-side fan 'e provider en foegje in mapping ta. De measte ymplemintaasjes jouwe jo in willekeurige eksterne port en litte jo de ynterne kieze, dus akseptearje de tawizing en rjochtsje dy op it tunneladres dat jo klant op dit stuit hat. Skriuw dat nûmer op, want elke lettere stap werhellet it krekt.

Providers dy't de mapping by opnij ferbinen rotearje, binne de gewoane reden dat dizze opset in jûn oerlibbet en dan stjert. Guon litte jo in stabile port oanfreegje, oaren jouwe by elke hânskikking in nije, dus lês de aktuele mappingside foardat jo eat oars oanreitsje.

Skeakel twa: oerstjoer de port mei in pf-anker

Op macOS heart de oerstjoering yn in pf-anker, ien regel per ynterface dy't it pakket drage kin. Skriuw de tunnelregel earst en de Ethernet-regel dêrnei, mei deselde eksterne port op beide, oars komt ferkear dat by in failover oer Wi-Fi oankomt, nearne telâne.

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

It ankerbestân op himsels docht neat; de haadkonfiguraasje moat dêrnei ferwize en it lade. Set dizze twa rigels yn /etc/pf.conf foar alle besteande oerstjoeringsregels, laad dan opnij en lês werom wat de kernel echt akseptearre 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

In syntaksisbeskuldiging oer in ûnbekende port betsjut dat in plakhâlder jo bewurking oerlibbe hat. In lege nat-tabel betsjut dat it anker nea laden is, en om't pf op hjoeddeistige macOS net standert oan is, heart sudo pfctl -E by de reparaasje en net by de opsjonele ekstra's. Laad it anker opnij nei elke werstart en nei elke mappingferoaring. Hâld it ankerbestân ûnder ferzje-behear, sadat in providerportferoaring in bewurking fan ien rigel wurdt ynstee fan in nije ûntdekkingstocht.

Skeakel trije: fêstje deselde port yn Plex

Iepenje yn Plex Ynstellingen, dan Tsjinner, dan Ôfstânstagon, en set in flakje by it fak dat jo in port mei de hân opjaan lit. Fier de eksterne port fan 'e provider yn ynstee fan 32400, en lit dan de berikberheidstest rinne. Nijere ferzjes hawwe dit bestjoer fan 'e âldere Connect-side wei ferpleatst, dus sjoch ûnder Ôfstânstagon as it fjild net is dêr't in hantlieding seit.

Testen fan 'e LAN bewiist hielendal neat. In laptop op deselde Wi-Fi berikt de tsjinner direkt, dus de probe slagget sels wylst it iepenbiere paad dea is. Brûk in tillefoan op mobile data, of hokker host dan ek bûten jo netwurk, en kies it iepenbiere adres en de eksterne port fan dêrút.

Befêstigje elke skeakel foardat jo Plex de skuld jouwe

Begjin by de harker en wurkje nei bûten. As Plex allinnich oan it LAN-adres bûn is, sil it in oerstjoering nei loopback negearje, dus it earste kommando is datjinge dat bewiist wêr't it harket.

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

Bewiis dêrnei dat de oerstjoering bestiet en oerienkomt mei de port dy't jo de provider jûn hawwe. De nat-tabel heart deselde eksterne port op beide ynterfaces te toanen.

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

Fier dat lêste kommando fan bûten it netwurk út, net fan 'e Mac. As de TCP-ferbining fan mobile data foltôge wurdt wylst Plex noch net beskikber toant, berikt de port de harker en is de oerbleaune fertochte it nûmer dat yn it Plex-fjild typt is. As der hielendal neat antwurdet, is de brek boppe stream: de mapping fan 'e provider, it tunneladres, of pf dat net oan is.