Ինչու է Plex-ի հեռավար մուտքը VPN-ի հետևում ձախողվում և ինչպես ուղղել այն

Հեռավար մուտքը դառնում է անհասանելի այն պահին, երբ VPN-ը վերցնում է լռելյայն երթուղին, մինչդեռ նույն սերվերը շարունակում է հեռարձակել դեպի LAN առանց բողոքի։ Plex-ի մատյաններում ոչինչ չի բացատրում փոփոխությունը, քանի որ Plex-ը կոտրված մասը չէ. այն հրապարակում է հասցե, ուր երթևեկությունն այլևս չի հասնում։ Մատակարարը, որը մեկ հանրային հասցե է կիսում հաճախորդների միջև, պորտ է փոխանցում ձեր թունելի հասցեին, և ձեր սեփական մեքենայի վրա ինչ-որ բան դեռ պետք է այդ պորտը տեղափոխի Plex-ի լսողին։ Բոլոր երեք օղակները պետք է համաձայնեն մեկ արտաքին պորտի շուրջ, նախքան հասանելիության թեստը կկանաչի։

Շղթան ունի երեք օղակ, և Plex-ը տեսնում է միայն վերջինը

Մատակարարը տիրապետում է հանրային հասցեի և իր պորտերից մեկը քարտեզագրում է ձեր թունելի հասցեին։ Ձեր մեքենան վերցնում է այդ պորտին եկած ամեն ինչ և վերահասցեավորում է Plex-ի լսողին, որը սովորաբար նստում է loopback 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 հասցեին, այն կանտեսի loopback-ին ուղղված վերահասցեավորումը, այնպես որ առաջին հրամանը այն է, որն ապացուցում է, թե որտեղ է այն լսում։

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-ը։