Kial Plex fora aliro malsukcesas malantaŭ VPN kaj kiel ripari ĝin

Fora aliro ruĝiĝas al neatingebla en la momento, kiam VPN transprenas la defaŭltan itineron, dum la sama servilo daŭre elsendas al la LAN sen plendo. Nenio en la protokoloj de Plex klarigas la ŝanĝon, ĉar Plex ne estas la parto, kiu rompiĝis: ĝi publikigas adreson, al kiu trafiko jam ne alvenas. Provizanto, kiu dividas unu publikan adreson inter klientoj, plusendas pordon al la adreso de via tunelo, kaj io en via propra maŝino ankoraŭ devas movi tiun pordon al la aŭskultanto de Plex. Ĉiuj tri ligoj devas konsenti pri unu ekstera pordo antaŭ ol la atingebla testo verdiĝos.

La ĉeno havas tri ligojn, kaj Plex vidas nur la lastan

La provizanto posedas publikan adreson kaj mapas unu el siaj pordoj al la adreso de via tunelo. Via maŝino prenas ĉion, kio alvenas sur tiun pordon, kaj alidirektas ĝin al la aŭskultanto de Plex, kiu kutime sidas sur la bukla pordo 32400. Poste oni diras al Plex la numeron de la ekstera pordo, por ke ĝia propra esploro kongruu kun tio, kion la ekstera mondo vokas.

Rompigu ajnan unuopan ligon kaj la retumila interfaco raportas foran aliron kiel neatingeblan, sen ajna aludo pri tio, kiu ligo fiaskis. Tiu silento estas la kialo, ke homoj restartigas la servilon, reinstalas la aplikaĵon kaj ŝaltas la agordon ree kaj ree sen movi la montrilon. La tri ligoj fiaskas sendepende: plusendo celanta malnoviĝintan tunelan adreson, alidirektado kiu kovras nur la Ethernet-interfacon, kaj Plex-kampo ankoraŭ tenanta 32400 ĉiuj produktas la saman ruĝan tekston. Laboru eksteren de la aŭskultanto anstataŭ diveni, kaj la difekta ligo kutime nombras sin mem ene de minuto.

Unua ligo: plusendu pordon ĉe la VPN-provizanto

Malfermu la pordan plusendan paĝon de la provizanto kaj aldonu mapadon. Plej multaj efektivigoj donas al vi hazardan eksteran pordon kaj lasas vin elekti la internan, do akceptu la atribuon kaj celigu ĝin al la tunela adreso, kiun via kliento nun tenas. Notu tiun numeron, ĉar ĉiu posta paŝo ripetas ĝin precize.

Provizantoj, kiuj rotacias la mapadon ĉe rekonekto, estas la kutima kialo, ke ĉi tiu agordo postvivas vesperon kaj poste mortas. Iuj lasas vin peti stabilan pordon, aliaj realjuĝas unu ĉe ĉiu manpremo, do legu la nunan mapadan paĝon antaŭ ol tuŝi ion alian.

Dua ligo: alidirektu la pordon per pf-ankro

En macOS la alidirektado apartenas al pf-ankro, unu regulo po interfaco, kiu povas porti la paketon. Skribu la tunelan regulon unue kaj la Ethernet-regulon due, kun la sama ekstera pordo sur ambaŭ, alie trafiko alvenanta per Wi-Fi dum malsukcesa transiro alteriĝas nenie.

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

La ankra dosiero sola faras nenion; la ĉefa agordo devas referenci ĝin kaj ŝargi ĝin. Metu ĉi tiujn du liniojn en /etc/pf.conf antaŭ ajnaj ekzistantaj alidirektaj reguloj, poste reŝargu kaj relegu, kion la kerno efektive akceptis.

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

Sintaksa plendo pri nekonata pordo signifas, ke lokokupilo postvivis vian redakton. Malplena nat-tabelo signifas, ke la ankro neniam ŝargiĝis, kaj ĉar pf ne estas ŝaltita defaŭlte en nuna macOS, sudo pfctl -E apartenas al la ripariĝo, ne al la laŭvolaj aldonaĵoj. Reŝargu la ankron post ĉiu restarto kaj post ĉiu mapada ŝanĝo. Tenu la ankran dosieron sub versikontrolo, por ke porda ŝanĝo ĉe la provizanto fariĝu unulinia redakto anstataŭ nova malkovro.

Tria ligo: fiksu la saman pordon ene de Plex

En Plex malfermu Agordojn, poste Servilon, poste Foran aliron, kaj marku la skatolon, kiu lasas vin specifi pordon permane. Entajpu la eksteran pordon de la provizanto anstataŭ 32400, poste lasu la atingeblan teston kuri. Pli novaj versioj movis ĉi tiun regilon for de la pli malnova paĝo Connect, do serĉu sub Fora aliro se la kampo ne estas tie, kie gvidilo asertas.

Testado el la LAN pruvas tute nenion. Tekkomputilo en la sama Wi-Fi atingas la servilon rekte, do la esploro sukcesas eĉ dum la publika vojo estas morta. Uzu telefonon kun movebla datumaro, aŭ ajnan gastiganton ekster via reto, kaj voku la publikan adreson kaj eksteran pordon de tie.

Konfirmu ĉiun ligon antaŭ ol kulpigi Plex

Komencu ĉe la aŭskultanto kaj laboru eksteren. Se Plex estas ligita nur al la LAN-adreso, ĝi ignoros alidirektadon celantan buklon, do la unua komando estas tiu, kiu pruvas, kie ĝi aŭskultas.

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

Poste pruvu, ke la alidirektado ekzistas kaj kongruas kun la pordo, kiun vi donis al la provizanto. La nat-tabelo devus montri la saman eksteran pordon sur ambaŭ interfacoj.

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

Rulu tiun lastan komandon de ekster la reto, ne de la Mac. Se la TCP-konekto kompletiĝas el movebla datumaro dum Plex ankoraŭ montras neatingeblon, la pordo atingas la aŭskultanton kaj la restanta suspektato estas la numero tajpita en la Plex-kampon. Se nenio respondas tute, la rompo estas pli supre: la mapado de la provizanto, la tunela adreso, aŭ pf ne ŝaltita.