De ce accesul la distanță Plex eșuează în spatele unui VPN și cum îl reparăm

Accesul la distanță trece în indisponibil în momentul în care un VPN preia ruta implicită, în timp ce același server continuă să transmită în LAN fără să se plângă. Nimic din jurnalele Plex nu explică schimbarea, pentru că Plex nu este partea care s-a stricat: publică o adresă în care traficul nu mai ajunge. Un furnizor care împarte o adresă publică între clienți redirecționează un port către adresa tunelului tău, iar ceva de pe propria mașină trebuie încă să mute acel port către ascultătorul Plex. Toate cele trei verigi trebuie să cadă de acord asupra unui port extern înainte ca testul de accesibilitate să devină verde.

Lanțul are trei verigi, iar Plex vede doar ultima

Furnizorul deține o adresă publică și mapează unul dintre porturile sale către adresa tunelului tău. Mașina ta ia tot ce ajunge pe acel port și redirecționează către ascultătorul Plex, care de obicei stă pe portul de buclă 32400. Apoi i se spune lui Plex numărul portului extern, astfel încât verificarea proprie să corespundă cu ce formează lumea exterioară.

Ruperea oricărei verigi face ca interfața web să raporteze accesul la distanță ca indisponibil, fără niciun indiciu despre care verigă a cedat. Această tăcere este motivul pentru care oamenii repornesc serverul, reinstalează aplicația și comută setarea iar și iar fără să miște acul. Cele trei verigi cedează independent: o redirecționare țintită către o adresă de tunel învechită, o redirecționare care acoperă doar interfața Ethernet și un câmp Plex care încă ține 32400 produc toate același text roșu. Lucrează de la ascultător spre exterior în loc să ghicești, iar veriga defectă de obicei se numește singură într-un minut.

Prima verigă: redirecționează un port la furnizorul VPN

Deschide pagina de redirecționare a porturilor a furnizorului și adaugă o mapare. Majoritatea implementărilor îți dau un port extern aleatoriu și te lasă să alegi portul intern, așa că acceptă alocarea și îndreaptă-o către adresa tunelului pe care o are clientul acum. Notează acel număr, pentru că fiecare pas ulterior îl repetă exact.

Furnizorii care rotesc maparea la reconectare sunt motivul obișnuit pentru care această configurare rezistă o seară și apoi moare. Unii te lasă să ceri un port stabil, alții alocă unul nou la fiecare strângere de mână, așa că citește pagina de mapare actuală înainte de a atinge altceva.

A doua verigă: redirecționează portul cu o ancoră pf

Pe macOS redirecționarea aparține unei ancore pf, o regulă pentru fiecare interfață care poate transporta pachetul. Scrie mai întâi regula tunelului și apoi regula Ethernet, cu același port extern pe ambele, altfel traficul care sosește prin Wi-Fi în timpul unei comutări de rezervă nu aterizează nicăieri.

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

Fișierul de ancoră singur nu face nimic; configurația principală trebuie să îl refere și să îl încarce. Pune aceste două linii în /etc/pf.conf înaintea oricăror reguli de redirecționare existente, apoi reîncarcă și citește ce a acceptat de fapt nucleul.

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

O reclamație de sintaxă despre un port necunoscut înseamnă că un substituent a supraviețuit modificării tale. Un tabel nat gol înseamnă că ancora nu a fost niciodată încărcată, iar din moment ce pf nu este activat implicit pe macOS actual, sudo pfctl -E face parte din remediere și nu din suplimentele opționale. Reîncarcă ancora după fiecare repornire și după fiecare schimbare de mapare. Ține fișierul de ancoră sub control de versiuni, astfel încât o schimbare de port la furnizor să devină o modificare de o linie, nu o nouă descoperire.

A treia verigă: fixează același port în interiorul Plex

În Plex deschide Setări, apoi Server, apoi Acces la distanță, și bifează căsuța care îți permite să specifici un port manual. Introdu portul extern al furnizorului în loc de 32400, apoi lasă testul de accesibilitate să ruleze. Versiunile mai noi au mutat acest control de pe pagina Connect mai veche, așa că uită-te sub Acces la distanță dacă câmpul nu este unde susține un ghid.

Testarea din LAN nu dovedește absolut nimic. Un laptop pe același Wi-Fi ajunge direct la server, așa că sonda reușește chiar și când calea publică este moartă. Folosește un telefon cu date mobile, sau orice gazdă din afara rețelei tale, și formează adresa publică și portul extern de acolo.

Confirmă fiecare verigă înainte de a da vina pe Plex

Începe cu ascultătorul și lucrează spre exterior. Dacă Plex este legat doar de adresa LAN, va ignora o redirecționare îndreptată spre buclă, așa că prima comandă este cea care dovedește unde ascultă.

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

Apoi dovedește că redirecționarea există și corespunde portului pe care l-ai dat furnizorului. Tabelul nat ar trebui să arate același port extern pe ambele interfețe.

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

Rulează acea ultimă comandă din afara rețelei, nu de pe Mac. Dacă conexiunea TCP se completează din date mobile în timp ce Plex încă arată indisponibil, portul ajunge la ascultător, iar suspectul rămas este numărul scris în câmpul Plex. Dacă nimic nu răspunde deloc, ruptura este mai sus: maparea furnizorului, adresa tunelului sau pf neactivat.