Pse aksesi në distancë i Plex dështon pas një VPN dhe si ta rregullosh

Aksesi në distancë kthehet në i padisponueshëm në momentin që një VPN merr rrugën e paracaktuar, ndërsa i njëjti server vazhdon të transmetojë në LAN pa u ankuar. Asgjë në regjistrat e Plex nuk e shpjegon ndryshimin, sepse Plex nuk është pjesa që u prish: ai publikon një adresë ku trafiku nuk arrin më. Një ofrues që ndan një adresë publike mes klientëve përcjell një port drejt adresës së tunelit tënd, dhe diçka në makinën tënde ende duhet ta zhvendosë atë port te dëgjuesi i Plex. Të tre hallkat duhet të bien dakord për një port të jashtëm përpara se testi i arritshmërisë të bëhet i gjelbër.

Zinxhiri ka tre hallka, dhe Plex sheh vetëm të fundit

Ofruesi zotëron një adresë publike dhe harton një nga portet e tij drejt adresës së tunelit tënd. Makina jote merr çdo gjë që arrin në atë port dhe e ridrejton te dëgjuesi i Plex, i cili zakonisht rri në portin e lakut 32400. Pastaj Plex njoftohet për numrin e portit të jashtëm, që sonda e tij të përputhet me atë që thërret bota e jashtme.

Thyej çdo hallkë të vetme dhe ndërfaqja e uebit raporton aksesin në distancë si të padisponueshëm, pa asnjë aluzion se cila hallkë dështoi. Ai heshtje është arsyeja pse njerëzit rinisin serverin, riinstalojnë aplikacionin dhe ndryshojnë cilësimin pa pushim pa e lëvizur gjilpërën. Të tre hallkat dështojnë në mënyrë të pavarur: një përcjellje e drejtuar nga një adresë e vjetruar tuneli, një ridrejtim që mbulon vetëm ndërfaqen Ethernet, dhe një fushë Plex që mban ende 32400 prodhojnë të njëjtin tekst të kuq. Punoni nga dëgjuesi drejt jashtë në vend që të hamendësoni, dhe hallka që dështon zakonisht e emëron veten brenda një minute.

Hallka e parë: përcill një port te ofruesi i VPN

Hap faqen e përcjelljes së porteve të ofruesit dhe shto një hartëzim. Shumica e implementimeve të japin një port të jashtëm të rastësishëm dhe të lënë të zgjedhësh atë të brendshëm, prandaj prano caktimin dhe drejtoje nga adresa e tunelit që klienti yt ka tani. Shkruaj atë numër, sepse çdo hap i mëpasshëm e përsërit saktësisht.

Ofruesit që rrotullojnë hartëzimin gjatë rilidhjes janë arsyeja e zakonshme pse ky konfigurim zgjat një mbrëmje dhe pastaj vdes. Disa të lënë të kërkosh një port të qëndrueshëm, të tjerë caktojnë një të re në çdo shtrëngim duarsh, prandaj lexo faqen aktuale të hartëzimit përpara se të prekësh çdo gjë tjetër.

Hallka e dytë: ridrejto portin me një spirancë pf

Në macOS ridrejtimi i takon një spirance pf, një rregull për çdo ndërfaqe që mund të mbajë paketën. Shkruaj rregullin e tunelit së pari dhe rregullin Ethernet më pas, me të njëjtin port të jashtëm në të dyja, përndryshe trafiku që arrin përmes Wi-Fi gjatë një kalimi rezervë nuk zbarkon askund.

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

Skedari i spirancës vetëm nuk bën asgjë; konfigurimi kryesor duhet t'i referohet dhe ta ngarkojë. Vendos këto dy rreshta në /etc/pf.conf përpara çdo rregulli ekzistues ridrejtimi, pastaj ringarko dhe lexo çfarë pranoi vërtet kerneli.

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

Një ankesë sintakse për një port të panjohur do të thotë që një mbajtës vendi i mbijetoi redaktimit tënd. Një tabelë nat bosh do të thotë që spiranca nuk u ngarkua kurrë, dhe meqenëse pf nuk është i aktivizuar si parazgjedhje në macOS aktual, sudo pfctl -E i takon rregullimit dhe jo shtesave fakultative. Ringarko spirancën pas çdo rindezjeje dhe pas çdo ndryshimi hartëzimi. Mbaje skedarin e spirancës nën kontroll versionesh, që një ndryshim porti te ofruesi të bëhet redaktim i një rreshti dhe jo një zbulim i ri.

Hallka e tretë: fikso të njëjtin port brenda Plex

Në Plex hap Cilësimet, pastaj Server, pastaj Akses në distancë, dhe shëno kutinë që të lejon të caktosh një port me dorë. Fut portin e jashtëm të ofruesit në vend të 32400, pastaj lëre testin e arritshmërisë të ekzekutohet. Ndërtimet më të reja e kanë zhvendosur këtë kontroll nga faqja e vjetër Connect, prandaj shiko nën Akses në distancë nëse fusha nuk është aty ku pretendon një udhëzues.

Testimi nga LAN nuk provon absolutisht asgjë. Një laptop në të njëjtin Wi-Fi arrin serverin drejtpërdrejt, prandaj sonda ka sukses edhe kur rruga publike është e vdekur. Përdor një telefon me të dhëna celulare, ose çdo host jashtë rrjetit tënd, dhe thirr adresën publike dhe portin e jashtëm prej andej.

Konfirmo çdo hallkë përpara se të fajësosh Plex

Fillo nga dëgjuesi dhe puno drejt jashtë. Nëse Plex është i lidhur vetëm me adresën LAN, do të injorojë një ridrejtim të drejtuar nga laku, prandaj komanda e parë është ajo që provon ku dëgjon.

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

Më pas, provo që ridrejtimi ekziston dhe përputhet me portin që i dhe ofruesit. Tabela nat duhet të tregojë të njëjtin port të jashtëm në të dyja ndërfaqet.

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

Ekzekuto atë komandë të fundit nga jashtë rrjetit, jo nga Mac. Nëse lidhja TCP përfundon nga të dhënat celulare ndërsa Plex vazhdon të tregojë i padisponueshëm, porti po arrin te dëgjuesi dhe i dyshuari i mbetur është numri i shtypur në fushën e Plex. Nëse asgjë nuk përgjigjet fare, thyerja është më lart: hartëzimi i ofruesit, adresa e tunelit, ose pf i paaktivizuar.