Miksi Plexin etäkäyttö epäonnistuu VPN:n takana ja miten se korjataan

Etäkäyttö muuttuu ei-saatavilla-tilaan sinä hetkenä, kun VPN ottaa oletusreitin haltuunsa, kun taas sama palvelin jatkaa suoratoistoa lähiverkkoon valittamatta. Mikään Plexin lokissa ei selitä muutosta, koska Plex ei ole se osa, joka hajosi: se julkaisee osoitteen, johon liikenne ei enää päädy. Palveluntarjoaja, joka jakaa yhden julkisen osoitteen asiakkaiden kesken, välittää portin tunneliosoitteeseesi, ja jotain omalla koneellasi täytyy yhä siirtää tuo portti Plexin kuuntelijalle. Kaikkien kolmen lenkin on sovittava yhdestä ulkoisesta portista ennen kuin saatavuustesti muuttuu vihreäksi.

Ketjussa on kolme lenkkiä, ja Plex näkee vain viimeisen

Palveluntarjoaja omistaa julkisen osoitteen ja kartoittaa yhden porteistaan tunneliosoitteeseesi. Koneesi ottaa kaiken, mikä saapuu tuolle portille, ja ohjaa sen Plexin kuuntelijalle, joka yleensä istuu loopback-portissa 32400. Sitten Plexille kerrotaan ulkoisen portin numero, jotta sen oma tunnustelu vastaa sitä, mitä ulkomaailma valitsee.

Katkaise mikä tahansa yksittäinen lenkki, ja verkkokäyttöliittymä ilmoittaa etäkäytön olevan ei saatavilla ilman vihjettä siitä, mikä lenkki petti. Se hiljaisuus on syy siihen, miksi ihmiset käynnistävät palvelimen uudelleen, asentavat sovelluksen uudelleen ja vaihtavat asetusta yhä uudelleen siirtämättä neulaa. Kolme lenkkiä pettävät toisistaan riippumatta: vanhentuneeseen tunneliosoitteeseen suunnattu edelleenohjaus, vain Ethernet-liittymän kattava uudelleenohjaus ja Plex-kenttä, joka yhä pitää 32400, tuottavat kaikki saman punaisen tekstin. Työskentele kuuntelijasta ulospäin arvaamisen sijaan, ja rikkinäinen lenkki nimeää itsensä yleensä minuutin kuluessa.

Ensimmäinen lenkki: välitä portti VPN-palveluntarjoajalla

Avaa palveluntarjoajan portin edelleenohjaussivu ja lisää kartoitus. Useimmat toteutukset antavat sinulle satunnaisen ulkoisen portin ja antavat valita sisäisen, joten hyväksy määritys ja suuntaa se tunneliosoitteeseen, joka asiakkaallasi on juuri nyt. Kirjoita numero muistiin, sillä jokainen myöhempi vaihe toistaa sen täsmälleen.

Palveluntarjoajat, jotka kierrättävät kartoitusta uudelleenyhdistettäessä, ovat tavallinen syy siihen, että tämä asetelma kestää illan ja kuolee sitten. Jotkut antavat pyytää pysyvää porttia, toiset määrittävät uuden joka kättelyssä, joten lue nykyinen kartoituksensivu ennen kuin kosket mihinkään muuhun.

Toinen lenkki: ohjaa portti uudelleen pf-ankkurilla

macOS:ssä uudelleenohjaus kuuluu pf-ankkuriin, yksi sääntö kutakin liittymää kohden, joka voi kuljettaa paketin. Kirjoita tunnelisääntö ensin ja Ethernet-sääntö toiseksi, samalla ulkoisella portilla molemmissa, muuten Wi-Fin kautta vikasietotilanteessa saapuva liikenne päätyy ei mihinkään.

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

Ankkuritiedosto yksinään ei tee mitään; pääkokoonpanon on viitattava siihen ja ladattava se. Laita nämä kaksi riviä /etc/pf.conf ennen kaikkia olemassa olevia uudelleenohjaussääntöjä, lataa sitten uudelleen ja lue takaisin, mitä ydin todella hyväksyi.

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

Syntaksivalitus tuntemattomasta portista tarkoittaa, että paikkamerkki selvisi muokkauksestasi. Tyhjä nat-taulukko tarkoittaa, että ankkuria ei koskaan ladattu, ja koska pf ei ole oletuksena käytössä nykyisessä macOS:ssä, sudo pfctl -E kuuluu korjaukseen eikä valinnaisiin lisäosiin. Lataa ankkuri uudelleen jokaisen uudelleenkäynnistyksen ja jokaisen kartoitusmuutoksen jälkeen. Pidä ankkuritiedosto versionhallinnassa, jotta palveluntarjoajan portin muutos on yhden rivin muokkaus eikä uusi löytöretki.

Kolmas lenkki: kiinnitä sama portti Plexin sisällä

Avaa Plexissä Asetukset, sitten Palvelin, sitten Etäkäyttö, ja rastita ruutu, joka sallii portin määrittämisen käsin. Kirjoita palveluntarjoajan ulkoinen portti 32400:n sijaan ja anna sitten saatavuustestin käynnistyä. Uudemmat versiot ovat siirtäneet tämän säätimen vanhalta Connect-sivulta, joten katso Etäkäytön alta, jos kenttä ei ole siinä, missä opas väittää.

Lähiverkosta testaaminen ei todista yhtään mitään. Samassa Wi-Fissä oleva kannettava tavoittaa palvelimen suoraan, joten tunnustelu onnistuu vaikka julkinen reitti olisi kuollut. Käytä matkapuhelindatan varassa olevaa puhelinta tai mitä tahansa isäntää verkkosi ulkopuolella ja valitse julkinen osoite ja ulkoinen portti sieltä.

Vahvista jokainen lenkki ennen kuin syytät Plexiä

Aloita kuuntelijasta ja työskentele ulospäin. Jos Plex on sidottu vain lähiverkon osoitteeseen, se jättää loopbackiin suunnatun uudelleenohjauksen huomiotta, joten ensimmäinen komento on se, joka todistaa, missä se kuuntelee.

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

Todista seuraavaksi, että uudelleenohjaus on olemassa ja vastaa porttia, jonka annoit palveluntarjoajalle. nat-taulukon pitäisi näyttää sama ulkoinen portti molemmissa liittymissä.

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

Suorita tuo viimeinen komento verkon ulkopuolelta, älä Macilta. Jos TCP-yhteys täydentyy matkapuhelindatasta samalla kun Plex yhä näyttää ei saatavilla -tilaa, portti saavuttaa kuuntelijan ja jäljelle jäävä epäilty on Plex-kenttään kirjoitettu numero. Jos mikään ei vastaa lainkaan, katkos on ylempänä: palveluntarjoajan kartoitus, tunneliosoite tai pf, jota ei ole otettu käyttöön.