Synology-ზე OpenVPN-ის ხელის ჩამორთმევა ვერ ხდება? შეამოწმეთ LAN-ის გადამისამართება

თქვენი ლეპტოპი აცხადებს, რომ TLS ხელის ჩამორთმევა ვერ მოხერხდა, ამიტომ სერტიფიკატების ხელახლა აწყობის ცდუნება ჩნდება. სანამ ამას გააკეთებთ, დასვით უფრო მოსაწყენი კითხვა: რომელ Ethernet პორტზე უსმენს Synology სინამდვილეში? ორი LAN პორტის მქონე NAS-ს ორი მისამართი აქვს, და DSM-ის VPN Server პაკეტი თავის OpenVPN მსმენელს ერთ-ერთ მათგანზე აბამს. როცა როუტერი 1194-ს სხვა მისამართზე გადაამისამართებს, არც ერთი პაკეტი ვერასოდეს აღწევს სერვისამდე, და კლიენტს სალაპარაკო არაფერი აქვს.

შეცდომის ტექსტი შეცდომაში შემყვანია, რადგან აღწერს უკანასკნელს, რაც კლიენტმა სცადა, და არა პირველს, რაც გაფუჭდა. ორი წუთი პაკეტის გვერდის როუტერის წესთან შედარებისთვის ამას წყვეტს.

იპოვეთ მისამართი, რომელზეც მსმენელია მიბმული

DSM თავის პორტებს LAN 1 და LAN 2-ს უწოდებს, და თითოეულს ცალკე მისამართი და ქვექსელი აქვს. გახსენით VPN Server, წაიკითხეთ OpenVPN ჩანართში დასახელებული ინტერფეისი, შემდეგ გახსენით მართვის პანელი და ჩაიწერეთ IPv4 მისამართი, რომელიც DSM-ს იმავე ინტერფეისზე აქვს. გადამისამართებამ სწორედ ეს ორი მნიშვნელობა უნდა დაასახელოს და არა NAS-ის ჰოსტის სახელი.

მეორე ჩართული კაბელი მეორე მსმენელს არ ქმნის. ორივე კავშირი დაკავშირებულად შეიძლება გამოჩნდეს, მაშინ როცა ტრაფიკს მხოლოდ ერთი მისამართი იღებს, და როცა ორივე ინტერფეისი ერთ ქვექსელშია, ორი მისამართი ერთი ციფრით განსხვავდება, რომელსაც წესის შენახვამდე არავინ გადაიკითხავს.

შეხედეთ თავად სოკეტს SSH-ის მეშვეობით, რადგან ეს ერთადერთი ადგილია, სადაც ჩანს, რასაც დემონი რეალურად მიება და არა ის, რასაც პარამეტრების გვერდი გულისხმობს.

sudo netstat -anp | grep 1194

შეცვალეთ არსებული გადამისამართება და ნუ დაამატებთ ახალს

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

external 1194/udp  ->  192.0.2.20:1194/udp

შიდა პორტი მსმენი პორტის ტოლი შეინახეთ და პროტოკოლი თანმიმდევრულად შეინარჩუნეთ. UDP 1194 ნაგულისხმევი მსმენელია, ხოლო TCP პროფილს საკუთარი მსმენელი სჭირდება პაკეტის მხარეს და შესაბამისი გადამისამართება როუტერზე. TCP-ის იმ სერვისზე გადამისამართება, რომელიც მხოლოდ UDP-ს უსმენს, სიჩუმეს იძლევა და არა შეცდომას.

თუ NAS-ის მისამართი DHCP-დან მოდის, დაჯავშნეთ იგი წესის შენახვამდე. იჯარის ამოწურვა მისამართს ხელახლა ანიჭებს, გადამისამართება კვლავ ძველ მნიშვნელობაზე მიუთითებს, და ხელის ჩამორთმევა იწყებს მარცხს იმ დღეს, როცა NAS-ს არავინ შეხებია. სტატიკური კონფიგურაცია NAS-ის მხარეს იმავე პრობლემას წყვეტს, თუ მისამართი როუტერის DHCP დიაპაზონს გარეთ არის.

დაამტკიცეთ, საერთოდ აღწევს თუ არა პაკეტები

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

sudo tcpdump -i any -n udp port 1194

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

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

როცა პაკეტები მოდის, შეწყვიტეთ გადამისამართების დადანაშაულება

პროფილი შემდეგი ეჭვმიტანილია, და ჩვეულებრივი მიზეზი ასაკია. ექსპორტირებული .ovpn ფაილი შეიცავს უფლებამოსილებას და მასალას ექსპორტის მომენტიდან, ამიტომ პაკეტი, რომლის სერტიფიკატიც მოგვიანებით შეიცვალა, უარყოფს კლიენტს, რომელსაც ჯერ კიდევ ძველი ასლი მიჰქონდა.

ტრანსპორტი კიდევ ერთი შეუთანხმებლობაა, რომლის ცალსახად შემოწმებაც ღირს, რადგან პროფილი და პაკეტი სხვადასხვა ადგილას იცვლება. პროფილის UDP-დან TCP-ზე გადართვა პაკეტის გადაურთავად ტოვებს კლიენტს ისეთი მსმენელის მოლოდინში, რომელიც არ არსებობს, და კლიენტი აცხადებს იმავე ზოგად ხელის ჩამორთმევის ტექსტს, რომელსაც ყველაფერ სხვაზე აცხადებს. წაიკითხეთ ფაილში proto სტრიქონი, შემდეგ ნახეთ სერვერის გვერდზე არჩეული პროტოკოლი, და მხოლოდ ამის შემდეგ დაასკვენით, რომ ისინი ემთხვევა. DSM-ის ფაიერვოლის წესების კითხვა მესამე შემოწმებაა: წესი, რომელიც პორტს ლოკალური ქვექსელიდან უშვებს და ინტერნეტიდან არა, ტესტირების შემდეგ ადვილად რჩება, და ის იძლევა კავშირს, რომელიც სამზარეულოდან მუშაობს და ყველა სხვა ადგილიდან მარცხდება.

შეამოწმეთ გზა, რომელსაც დისტანციური მომხმარებელი რეალურად გადის

იმავე LAN-ის შიგნით მყოფ კლიენტს NAS-მდე მისვლა გადამისამართებაზე ხელის შეხების გარეშე შეუძლია, ამიტომ ეს დისტანციური წვდომის შესახებ არაფერს ამტკიცებს. გამოიყენეთ გამორთული Wi-Fi-ის მქონე ტელეფონი, ან ჰკითხეთ ქსელის გარეთ მყოფ ადამიანს, და თვალი ადევნეთ როუტერის მრიცხველს იმ ცდის დროს. თუ დისტანციური ცდა მარცხდება და ლოკალური წარმატებულია, გადამისამართება ან ფაიერვოლი ჯერ კიდევ სურათშია.

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