Bakit nabibigo ang malayuang pag-access ng Plex sa likod ng VPN at paano ito ayusin
Ang malayuang pag-access ng Plex sa likod ng VPN ay nangangailangan ng tatlong kawing: port forwarding sa provider, lokal na pf redirect at ang parehong panlabas na port na itinatype sa Plex.
Nagiging hindi available ang malayuang pag-access sa sandaling sakupin ng VPN ang default na ruta, habang ang parehong server ay patuloy na nag-stream sa LAN nang walang reklamo. Wala sa mga log ng Plex ang nagpapaliwanag ng pagbabago, dahil ang Plex ay hindi ang bahaging nasira: naglalathala ito ng address kung saan hindi na dumarating ang trapiko. Ang provider na nagbabahagi ng isang pampublikong address sa mga customer ay nagpapasa ng port sa address ng iyong tunnel, at may isang bagay sa iyong sariling makina na kailangan pa ring maglipat ng port na iyon sa listener ng Plex. Dapat magkasundo ang tatlong kawing sa isang panlabas na port bago maging berde ang pagsubok sa maabot.
May tatlong kawing ang kadena, at nakikita lamang ng Plex ang huli
Pagmamay-ari ng provider ang isang pampublikong address at ini-map ang isa sa mga port nito sa address ng iyong tunnel. Kinukuha ng iyong makina ang lahat ng dumarating sa port na iyon at inirere-direct sa listener ng Plex, na karaniwang nakaupo sa loopback port 32400. Pagkatapos ay sinasabihan ang Plex ng numero ng panlabas na port upang tumugma ang sarili nitong probe sa dinadayal ng labas na mundo.
Putulin ang alinmang kawing at iniuulat ng web interface ang malayuang pag-access bilang hindi available, nang walang anumang bakas kung aling kawing ang nabigo. Ang katahimikang iyon ang dahilan kung bakit paulit-ulit na nire-restart ng mga tao ang server, ini-install muli ang app at binabalik-balik ang setting nang hindi gumagalaw ang karayom. Nabibigo nang magkahiwalay ang tatlong kawing: isang forwarding na nakaturo sa lumang address ng tunnel, isang redirect na sumasakop lamang sa interface ng Ethernet, at isang field ng Plex na hawak pa rin ang 32400 ay gumagawa ng parehong pulang teksto. Magtrabaho mula sa listener pakanluran sa halip na manghula, at ang sirang kawing ay karaniwang nagpapangalan sa sarili sa loob ng isang minuto.
Unang kawing: mag-forward ng port sa provider ng VPN
Buksan ang page ng port forwarding ng provider at magdagdag ng mapping. Karamihan sa mga implementasyon ay nagbibigay sa iyo ng random na panlabas na port at hinahayaan kang pumili ng panloob, kaya tanggapin ang pagtatalaga at ituro ito sa address ng tunnel na hawak ng iyong client ngayon. Isulat ang numerong iyon, dahil inuulit ito nang eksakto ng bawat susunod na hakbang.
Ang mga provider na nagrorotate ng mapping kapag muling kumonekta ang karaniwang dahilan kung bakit ang setup na ito ay tumatagal ng isang gabi at pagkatapos ay namamatay. Ang ilan ay hinahayaan kang humiling ng matatag na port, ang iba ay naglalaan ng bago sa bawat handshake, kaya basahin ang kasalukuyang page ng mapping bago hawakan ang anumang iba.
Ikalawang kawing: i-redirect ang port gamit ang pf anchor
Sa macOS, ang redirect ay kabilang sa pf anchor, isang patakaran sa bawat interface na kayang magdala ng packet. Isulat muna ang patakaran ng tunnel at pagkatapos ang patakaran ng Ethernet, na may parehong panlabas na port sa dalawa, kung hindi ay hindi makakarating kahit saan ang trapikong dumarating sa Wi-Fi habang may failover.
# /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
Ang anchor file lamang ay walang ginagawa; kailangan itong i-reference at i-load ng pangunahing configuration. Ilagay ang dalawang linyang ito sa /etc/pf.conf bago ang anumang umiiral na patakaran sa redirect, pagkatapos ay i-reload at basahin kung ano talaga ang tinanggap ng 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
Ang reklamo sa syntax tungkol sa hindi kilalang port ay nangangahulugang may placeholder na nakaligtas sa iyong pag-edit. Ang walang laman na talahanayan ng nat ay nangangahulugang hindi kailanman na-load ang anchor, at dahil ang pf ay hindi naka-enable bilang default sa kasalukuyang macOS, sudo pfctl -E ay bahagi ng pag-aayos at hindi ng mga opsyonal na dagdag. I-reload ang anchor pagkatapos ng bawat reboot at pagkatapos ng bawat pagbabago sa mapping. Panatilihin ang anchor file sa ilalim ng version control upang ang pagbabago ng port sa provider ay maging isang linyang pag-edit sa halip na isang bagong pagtuklas.
Ikatlong kawing: i-pin ang parehong port sa loob ng Plex
Sa Plex, buksan ang Mga Setting, pagkatapos ang Server, pagkatapos ang Malayuang Pag-access, at lagyan ng tsek ang kahon na nagpapahintulot sa iyo na tukuyin ang port nang manu-mano. Ilagay ang panlabas na port ng provider sa halip na 32400, pagkatapos ay hayaang tumakbo ang pagsubok sa maabot. Inilipat ng mas bagong build ang kontrol na ito palayo sa lumang page ng Connect, kaya tingnan sa ilalim ng Malayuang Pag-access kung wala ang field sa sinasabi ng gabay.
Ang pagsubok mula sa LAN ay walang pinatutunayan. Ang laptop sa parehong Wi-Fi ay direktang nakakarating sa server, kaya nagtatagumpay ang probe kahit patay ang pampublikong ruta. Gumamit ng teleponong may cellular data, o anumang host sa labas ng iyong network, at i-dial ang pampublikong address at panlabas na port mula roon.
Kumpirmahin ang bawat kawing bago sisihin ang Plex
Magsimula sa listener at magtrabaho pakanluran. Kung ang Plex ay nakatali lamang sa address ng LAN, hindi papansinin nito ang isang redirect na nakaturo sa loopback, kaya ang unang utos ay ang nagpapatunay kung saan ito nakikinig.
sudo lsof -nP -iTCP:32400 -sTCP:LISTEN
Susunod, patunayan na umiiral ang redirect at tumutugma sa port na ibinigay mo sa provider. Dapat ipakita ng talahanayan ng nat ang parehong panlabas na port sa dalawang interface.
sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893
Patakbuhin ang huling utos na iyon mula sa labas ng network, hindi mula sa Mac. Kung ang koneksyon ng TCP ay natapos mula sa cellular data habang ang Plex ay nagpapakita pa ring hindi available, naaabot ng port ang listener at ang natitirang pinaghihinalaan ay ang numerong itinatype sa field ng Plex. Kung wala talagang sumasagot, ang putol ay nasa itaas: ang mapping ng provider, ang address ng tunnel, o ang pf na hindi naka-enable.