Чаму аддалены доступ да Plex не працуе праз VPN і як гэта выправіць
Для аддаленага доступу да Plex праз VPN патрэбныя тры звёны: перанакіраванне порта ў правайдэра, лакальнае перанакіраванне pf і той жа знешні порт, уведзены ў Plex.
Аддалены доступ ператвараецца ў недаступны ў тую ж хвіліну, калі VPN перахоплівае маршрут па змаўчанні, а той жа сервер працягвае трансляваць у лакальную сетку без скаргаў. Нішто ў журналах Plex не тлумачыць змену, бо Plex не з'яўляецца тым, што зламалася: ён публікуе адрас, куды трафік больш не трапляе. Правайдэр, які дзеліць адзін публічны адрас паміж кліентамі, перанакіроўвае порт на адрас вашага тунэля, і нешта на вашай уласнай машыне ўсё яшчэ павінна перанесці гэты порт на слухач Plex. Усе тры звёны павінны ўзгадніць адзін знешні порт, перш чым праверка даступнасці стане зялёнай.
Ланцуг мае тры звёны, а Plex бачыць толькі апошняе
Правайдэр валодае публічным адрасам і супастаўляе адзін са сваіх партоў з адрасам вашага тунэля. Ваша машына бярэ ўсё, што прыходзіць на гэты порт, і перанакіроўвае гэта на слухач Plex, які звычайна сядзіць на петлявым порце 32400. Затым Plex паведамляюць нумар знешняга порта, каб яго ўласная праверка супадала з тым, што набірае знешні свет.
Парушце любое адно звяно, і вэб-інтэрфейс паведаміць пра аддалены доступ як недаступны, без намёку на тое, якое звяно адмовіла. Гэтая цішыня — прычына, чаму людзі перазапускаюць сервер, пераўсталёўваюць праграму і раз за разам перамыкаюць наладу, не зрушваючы справу з месца. Тры звёны адмаўляюць незалежна: перанакіраванне, нацэленае на састарэлы адрас тунэля, перанакіраванне, якое ахоплівае толькі інтэрфейс Ethernet, і поле Plex, якое ўсё яшчэ ўтрымлівае 32400, даюць аднолькавы чырвоны тэкст. Ідзіце ад слухача вонкі замест здагадак, і зламанае звяно звычайна называе сябе на працягу хвіліны.
Звяно першае: перанакіруйце порт у правайдэра VPN
Адкрыйце старонку перанакіравання партоў правайдэра і дадайце супастаўленне. Большасць рэалізацый даюць выпадковы знешні порт і дазваляюць выбраць унутраны, таму прымеце прызначэнне і нацэльце яго на адрас тунэля, які ваш кліент трымае цяпер. Запішыце гэты нумар, бо кожны наступны крок паўтарае яго дакладна.
Правайдэры, якія змяняюць супастаўленне пры перападключэнні, — звычайная прычына таго, што гэтая налада трымаецца вечар, а потым памірае. Некаторыя дазваляюць запытаць стабільны порт, іншыя прызначаюць новы пры кожным рукапацісканні, таму прачытайце бягучую старонку супастаўлення, перш чым чапаць што-небудзь яшчэ.
Звяно другое: перанакіруйце порт праз якар pf
На macOS перанакіраванне належыць у якар pf, адно правіла на кожны інтэрфейс, які можа несці пакет. Напішыце правіла тунэля першым, а правіла Ethernet другім, з аднолькавым знешнім портам на абодвух, інакш трафік, які прыходзіць праз Wi-Fi падчас пераключэння, трапляе ў нікуды.
# /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
Файл якара сам па сабе нічога не робіць; галоўная канфігурацыя павінна спасылацца на яго і загружаць яго. Змясціце гэтыя два радкі ў /etc/pf.conf перад любымі існуючымі правіламі перанакіравання, затым перазагрузіце і прачытайце, што ядро сапраўды прыняло.
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
Скарга на сінтаксіс з-за невядомага порта азначае, што запаўняльнік перажыў вашую праўку. Пустая табліца nat азначае, што якар так і не загрузіўся, а паколькі pf не ўключаны па змаўчанні ў сучасных macOS, sudo pfctl -E належыць да выпраўлення, а не да неабавязковых дадаткаў. Перазагружайце якар пасля кожнага перазапуску і пасля кожнай змены супастаўлення. Трымайце файл якара пад кантролем версій, каб змена порта ў правайдэра стала праўкай у адзін радок, а не новым пошукам.
Звяно трэцяе: замацуйце той жа порт унутры Plex
У Plex адкрыйце Налады, затым Сервер, затым Аддалены доступ і пастаўце птушку ў полі, якое дазваляе ўказаць порт уручную. Увядзіце знешні порт правайдэра замест 32400, затым дайце працы праверцы даступнасці. Новыя зборкі перанеслі гэты элемент кіравання далей ад старой старонкі Connect, таму шукайце ў раздзеле Аддалены доступ, калі поле не там, дзе сцвярджае кіраўніцтва.
Праверка з LAN не даказвае нічога. Ноўтбук у той жа Wi-Fi дасягае сервера напрамкі, таму праверка паспяховая нават тады, калі публічны шлях мёртвы. Выкарыстайце тэлефон на мабільных даных або любы хост па-за вашай сеткай і набярыце публічны адрас і знешні порт адтуль.
Пацвердзіце кожнае звяно, перш чым вінаваціць Plex
Пачніце са слухача і рухайцеся вонкі. Калі Plex прывязаны толькі да адраса LAN, ён праігнаруе перанакіраванне, нацэленае на петлю, таму першая каманда — тая, што даказвае, дзе ён слухае.
sudo lsof -nP -iTCP:32400 -sTCP:LISTEN
Далей дакажыце, што перанакіраванне існуе і супадае з портам, які вы аддалі правайдэру. Табліца nat павінна паказваць той жа знешні порт на абодвух інтэрфейсах.
sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893
Выканайце апошнюю каманду з-за меж сеткі, а не з Mac. Калі злучэнне TCP завяршаецца з мабільных даных, а Plex усё яшчэ паказвае недаступнасць, порт дасягае слухача, і рэшткавы падазроны — гэта нумар, уведзены ў поле Plex. Калі нішто не адказвае зусім, разрыў вышэй: супастаўленне ў правайдэра, адрас тунэля або няўключаны pf.