რატომ ვერ მუშაობს Plex-ის დისტანციური წვდომა VPN-ის უკან და როგორ გამოვასწოროთ

დისტანციური წვდომა მიუწვდომლად იქცევა იმ წამს, როცა VPN ნაგულისხმევ მარშრუტს იბარებს, მაშინ როცა იგივე სერვერი უკმაყოფილოდ აგრძელებს LAN-ზე სტრიმინგს. Plex-ის ჟურნალებში ცვლილებას არაფერი ხსნის, რადგან Plex არ არის ის ნაწილი, რომელიც გატყდა: ის აქვეყნებს მისამართს, სადაც ტრაფიკი აღარ ხვდება. პროვაიდერი, რომელიც ერთ საჯარო მისამართს ყოფს კლიენტებს შორის, პორტს თქვენი გვირაბის მისამართზე გადაამისამართებს, და თქვენს მანქანაზე რაღაც მაინც უნდა გადაიტანოს ეს პორტი Plex-ის მსმენელთან. სამივე რგოლი ერთ გარე პორტზე უნდა შეთანხმდეს, სანამ ხელმისაწვდომობის ტესტი მწვანე გახდება.

ჯაჭვს სამი რგოლი აქვს, და Plex მხოლოდ უკანასკნელს ხედავს

პროვაიდერი ფლობს საჯარო მისამართს და თავის ერთ პორტს თქვენი გვირაბის მისამართზე ასახავს. თქვენი მანქანა იღებს ყველაფერს, რაც ამ პორტზე მოდის, და Plex-ის მსმენელზე გადაამისამართებს, რომელიც ჩვეულებრივ loopback პორტ 32400-ზე ზის. შემდეგ Plex-ს ეუბნებიან გარე პორტის ნომერს, რომ მისი საკუთარი შემოწმება გარე სამყაროს აკრეფილს დაემთხვეს.

გატეხეთ ნებისმიერი ერთი რგოლი და ვებ ინტერფეისი დისტანციურ წვდომას მიუწვდომლად აცხადებს, ყოველგვარი მინიშნების გარეშე, რომელი რგოლი ჩავარდა. ეს სიჩუმეა მიზეზი, რატომ გადატვირთავენ ადამიანები სერვერს, ხელახლა აყენებენ აპს და პარამეტრს ისევ და ისევ ცვლიან ისრის განძრევის გარეშე. სამი რგოლი დამოუკიდებლად ცვივა: მოძველებულ გვირაბის მისამართზე მიმართული გადაგზავნა, მხოლოდ Ethernet ინტერფეისს დაფარვის გადამისამართება და ჯერ კიდევ 32400-ის შემცველი Plex-ის ველი, ყველა ერთსა და იმავე წითელ ტექსტს იძლევა. იმუშავეთ მსმენელიდან გარეთკენ, ვიდრე გამოიცნობთ, და დაზიანებული რგოლი ჩვეულებრივ წუთში თავად ასახელებს თავს.

პირველი რგოლი: გადაუგზავნეთ პორტი 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.