Miért vall kudarcot a Plex távoli hozzáférése VPN mögött, és hogyan javítsuk

A távoli hozzáférés abban a pillanatban elérhetetlenné válik, amikor a VPN átveszi az alapértelmezett útvonalat, miközben ugyanaz a kiszolgáló panasz nélkül streamel a LAN felé. Semmi nem magyarázza a változást a Plex naplóiban, mert nem a Plex az a rész, amely elromlott: olyan címet tesz közzé, ahová a forgalom már nem érkezik meg. Egy szolgáltató, amely egy nyilvános címet oszt meg az ügyfelek között, egy portot továbbít a tunnel címére, és valaminek a saját gépén még mindig át kell vinnie azt a portot a Plex figyelőjéhez. Mindhárom láncszemnek meg kell egyeznie egyetlen külső portban, mielőtt az elérhetőségi teszt zöldre vált.

A láncnak három láncszeme van, és a Plex csak az utolsót látja

A szolgáltatónak van egy nyilvános címe, és az egyik portját a tunnel címére képezi le. A gépe fogja, ami ezen a porton érkezik, és átirányítja a Plex figyelőjéhez, amely általában a loopback 32400-as porton ül. Ezután a Plexnek megmondják a külső port számát, hogy a saját próbája egyezzen azzal, amit a külvilág tárcsáz.

Törje meg bármelyik láncszemet, és a webes felület elérhetetlenként jelenti a távoli hozzáférést, anélkül hogy bármit is sejtetne arról, melyik láncszem hibázott. Ez a csend az oka annak, hogy az emberek újraindítják a kiszolgálót, újratelepítik az alkalmazást, és újra meg újra átkapcsolják a beállítást anélkül, hogy a mutató elmozdulna. A három láncszem egymástól függetlenül hibázik: egy elavult tunnelcímre irányuló továbbítás, egy csak az Ethernet-interfészt lefedő átirányítás és egy még mindig 32400-at tartó Plex-mező mind ugyanazt a piros szöveget eredményezi. A figyelőtől kifelé dolgozzon találgatás helyett, és a hibás láncszem általában egy percen belül megnevezi magát.

Első láncszem: továbbítson egy portot a VPN-szolgáltatónál

Nyissa meg a szolgáltató porttovábbítási oldalát, és adjon hozzá egy leképezést. A legtöbb megvalósítás véletlenszerű külső portot ad, és a belsőt Ön választhatja ki, ezért fogadja el a hozzárendelést, és irányítsa a tunnel címére, amely az ügyfelénél éppen van. Írja fel ezt a számot, mert minden későbbi lépés pontosan megismétli.

Azok a szolgáltatók, amelyek újracsatlakozáskor forgatják a leképezést, a szokásos oka annak, hogy ez a beállítás kibír egy estét, majd meghal. Egyesek kérhetővé teszik a stabil portot, mások minden kézfogásnál újat osztanak ki, ezért olvassa el az aktuális leképezési oldalt, mielőtt bármi máshoz nyúlna.

Második láncszem: irányítsa át a portot pf-horgonnyal

macOS-en az átirányítás pf-horgonyba tartozik, egy szabály minden interfészhez, amely el tudja vinni a csomagot. Először a tunnel szabályt írja meg, utána az Ethernet szabályt, mindkettőn ugyanazzal a külső porttal, különben a feladatátvétel alatt Wi-Fi-n érkező forgalom sehová nem érkezik meg.

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

A horgonyfájl önmagában semmit nem tesz; a fő konfigurációnak hivatkoznia kell rá és be kell töltenie. Tegye ezt a két sort a /etc/pf.conf fájlba bármely meglévő átirányítási szabály elé, majd töltse újra, és olvassa vissza, mit fogadott el valójában a kernel.

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

Egy ismeretlen portra vonatkozó szintaktikai panasz azt jelenti, hogy egy helyőrző túlélte a szerkesztését. Az üres nat-tábla azt jelenti, hogy a horgony soha nem töltődött be, és mivel a pf a jelenlegi macOS-en alapértelmezés szerint nincs engedélyezve, a sudo pfctl -E a javítás része, nem az opcionális extráké. Minden újraindítás után és minden leképezésváltozás után töltse újra a horgonyt. Tartsa a horgonyfájlt verziókezelés alatt, hogy a szolgáltatói portváltozás egyetlen soros szerkesztés legyen újrafelfedezés helyett.

Harmadik láncszem: rögzítse ugyanazt a portot a Plexben

A Plexben nyissa meg a Beállításokat, majd a Kiszolgálót, majd a Távoli hozzáférést, és pipálja ki a négyzetet, amely lehetővé teszi a port kézi megadását. A 32400 helyett írja be a szolgáltató külső portját, majd hagyja lefutni az elérhetőségi tesztet. Az újabb buildek elmozdították ezt a vezérlőt a régebbi Connect-oldalról, ezért nézzen a Távoli hozzáférés alá, ha a mező nem ott van, ahol egy útmutató állítja.

A LAN-ból tesztelni semmit sem bizonyít. Az ugyanazon a Wi-Fi-n lévő laptop közvetlenül eléri a kiszolgálót, így a próba akkor is sikerül, amikor a nyilvános útvonal halott. Használjon mobiladatot használó telefont vagy bármely, a hálózatán kívüli gazdagépet, és onnan tárcsázza a nyilvános címet és a külső portot.

Erősítse meg mindegyik láncszemet, mielőtt a Plexet hibáztatja

Kezdje a figyelőnél, és dolgozzon kifelé. Ha a Plex csak a LAN-címhez van kötve, figyelmen kívül hagyja a loopbackre irányuló átirányítást, ezért az első parancs az, amely bizonyítja, hol hallgat.

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

Ezután bizonyítsa, hogy az átirányítás létezik, és megfelel annak a portnak, amelyet a szolgáltatónak adott. A nat-táblának ugyanazt a külső portot kell mutatnia mindkét interfészen.

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

Futtassa ezt az utolsó parancsot a hálózaton kívülről, ne a Macről. Ha a TCP-kapcsolat mobiladatról létrejön, miközben a Plex még mindig elérhetetlent mutat, a port eléri a figyelőt, és a maradék gyanúsított a Plex-mezőbe írt szám. Ha semmi sem válaszol egyáltalán, a törés feljebb van: a szolgáltatói leképezés, a tunnel címe vagy a nem engedélyezett pf.