როგორ შევამოწმოთ OpenVPN პროფილის სერვერი იმპორტამდე

ვიღაც გიგზავნით პროფილს, თქვენ იმპორტავთ მას და ოცდაათი წამის შემდეგ რომელიმე კლიენტი ურეკავს დანიშნულებას, რომელიც არავის შეუმოწმებია. ჯერ წაიკითხეთ ფაილი ტექსტურ რედაქტორში, რადგან ყველაფერი მნიშვნელოვანი მუჭა დირექტივაში ჯდება: remote, proto, port, ca, cert, tls-crypt და verify-x509-name. დანარჩენი ნაგულისხმევი მნიშვნელობებია და სწორედ იქ ცხოვრობს სიურპრიზები.

ჩამოთვალეთ ყველა საბოლოო წერტილი, რომლის გამოყენებაც ფაილს შეუძლია

დაიწყეთ საბოლოო წერტილებიდან, რადგან ერთი პროფილი რამდენიმეს შეიცავს. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn ბეჭდავს ყოველ კანდიდატს ფაილის რიგითობით, მათ შორის ჩაშენებულ <connection> ბლოკებში მოთავსებულებს.

როცა დირექტივა პორტს გამოტოვებს, კლიენტი მსმენელის ნაგულისხმევ მნიშვნელობას უბრუნდება, ამიტომ მხოლოდ remote vpn.example.com ნიშნავს 1194 პორტს, ფაილში მოგვიანებით გამოჩენილი ნებისმიერი proto-ის მიუხედავად. რამდენიმე უბრალო remote ხაზი ალტერნატივაა: კლიენტი რიგით ცდის მათ, თუ remote-random არ აურევს, და არასოდეს ცვლის ჩუმად სხვა ოპერატორის ჰოსტს. ორი remote ხაზი დაუკავშირებელ დომენებზე ის ადგილია, სადაც ჩერდებით და ეკითხებით, რომელი იყო გულისხმობილი.

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

ჯერ დაადასტურეთ სახელი, შემდეგ პორტი

dig +short vpn.example.com გეუბნებათ, არსებობს თუ არა სახელი და რომელ მისამართებს აბრუნებს, და მრავალმისამართიანი ან პროქსის უკან მყოფი საბოლოო წერტილი ლეგიტიმურად შეიძლება რამდენიმეს აბრუნებდეს. სახელის ამოხსნა წინაპირობაა და არა საკუთრების მტკიცებულება; ნებისმიერს შეუძლია სახელი მისამართზე მიუთითოს და ერთი მისამართი ბევრ სახელს უპასუხოს.

შემდეგ შეამოწმეთ მსმენელი იმ პორტზე, რომელიც იპოვეთ, ტრანსპორტის შესაბამისად. TCP-ზე openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ბეჭდავს იმ ჯაჭვს, რომელსაც სერვერი წარმოადგენს. UDP-ზე გჭირდებათ DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 იგივე ხელის ჩამორთმევას ასრულებს დატაგრამებზე. დასრულებული ხელის ჩამორთმევა ამტკიცებს, რომ რაღაც ისმენს და სერტიფიკატს ფლობს — ეს მეტია იმაზე, რასაც ping აჩვენებს და ნაკლები იმაზე, რასაც თავად პროფილის ნდობის პარამეტრები მოითხოვს.

როცა ხელის ჩამორთმევა ვარდება და ჰოსტი ping-ს პასუხობს, პორტი სავარაუდოდ არასწორია ან გაფილტრული. მიიღეთ ეს სწორი პორტის მოთხოვნის მიზეზად და არა მეზობელი პორტების გაწმენდის მოწვევად. nc -vzu ზოგიერთ სტეკზე წარმატებას აცხადებს მაშინაც, როცა არაფერი ისმენს, ამიტომ შიშველი UDP გამოცდა არაფერს ნიშნავს მის უკან ხელის ჩამორთმევის გარეშე.

ნდობის ქინძისთავები მისამართისგან ცალკე წაიკითხეთ

მისამართი წყვეტს, სად მიდის კლიენტი; ნდობის ბლოკი წყვეტს, ვის სჯერა ჩასვლისას. verify-x509-name "vpn.example.com" name ამაგრებს სუბიექტის საერთო სახელს, ხოლო remote-cert-tls server მოითხოვს გაფართოებული გასაღების გამოყენებას სერვერის აუთენტიფიკაციისთვის. ოპერატორის მოცემულ პროფილს ორივე უნდა ჰქონდეს.

მოძებნეთ ca, ჩაშენებული <ca> ბლოკი და ან tls-crypt, ან tls-auth. tls-auth-ის მქონე პროფილს კლიენტზე სჭირდება key-direction 1, როცა სერვერის მხარე 0 მიმართულებას იყენებს, და შეუთავსებლობა ხელის ჩამორთმევას ამარცხებს TLS შეცდომით, რომელიც სერტიფიკატის ხარვეზად იკითხება. ჩაშენებული CA, რომელიც არ ეკუთვნის იმ ოპერატორს, რომლის სახელიც ახლახან ამოხსენით, ნიშნავს, რომ ფაილი ორი წყაროდან არის აწყობილი, და სწორედ ესაა საქმე, რომლის მკაცრად უარყოფაც ღირს.

verify-x509-name იღებს name, name-prefix ან subject რეჟიმებს, და უკანასკნელი სრულ განმასხვავებელ სახელს ელოდება ზუსტად იმ რიგითობით, რომლითაც სერვერი ბეჭდავს. აირჩიეთ რეჟიმი, რომელიც მნიშვნელობის ფორმას შეესაბამება, რადგან კლიენტი ყოველ კავშირს უარყოფს ნაცვლად იმისა, რომ ახლო გაშვებაზე გააფრთხილოს. ფაილისთვის, რომელიც თქვენ არ დაგიწერიათ, უბრალო ჰოსტის სახელით name ყველაზე ნაკლებად გასაკვირი არჩევანია.

შეამოწმეთ პარამეტრები, რომლებიც ჩუმად ვარდება

OpenVPN 2.6 შიფრებზე data-ciphers-ის მეშვეობით თანხმდება, და პროფილი, რომელსაც მხოლოდ ძველი cipher AES-256-CBC ხაზი აქვს, შეიძლება საკონტროლო არხი დაასრულოს და შემდეგ მონაცემებზე გაჩერდეს. ამ მნიშვნელობის წაკითხვა გეუბნებათ, ფაილი უფრო ძველია თუ არა იმ სერვერზე, რომელსაც უერთდებით; 2.6-ის სახელმძღვანელოს გვერდი თანხმობის რიგს ჩამოთვლის, თუ ოპერატორისთვის ციტირება დაგჭირდათ.

ფაილის სახელის გარეშე auth-user-pass ნიშნავს, რომ კლიენტი იკითხავს, ამიტომ თვითკმარი შთაბეჭდილების მქონე პროფილს მაინც სჭირდება რწმუნებები. auth-user-pass credentials.txt ნიშნავს, რომ ის ელოდება ფაილს, რომელიც სავარაუდოდ არ გამოგიგზავნეს. nobind და resolv-retry infinite ჩვეულებრივი და უვნებელია, მაშინ როცა explicit-exit-notify მხოლოდ UDP-სთვისაა და TCP-ზე უაზრო.

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

გადაწყვიტეთ და შემდეგ ჩაწერეთ, რა გადაწყვიტეთ

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

ჩაწერეთ hash, რომელიც გადახედეთ, რათა შემდეგმა ადამიანმა იცოდეს, შეიცვალა თუ არა ფაილი: sha256sum profile.ovpn, მიკრული საბოლოო წერტილის გვერდით თქვენს ჩანაწერებში. პროფილი მთლიანი განლაგებაა და არა მისამართების სია, ამიტომ არასოდეს ჩასვათ მომუშავე remote სხვის ნდობის ბლოკში მათი რწმუნებების შენარჩუნებით.

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

თუ მაინც იმპორტავთ და პირველი ცდა ვარდება, გაუშვით კლიენტი --verb 3-ით და წაიკითხეთ პირველი ათი სტრიქონი: ამოხსნილი remote მისამართი, შეთანხმებული proto და TLS შეცდომა ამ რიგით ჩნდება, რაც გეუბნებათ, ზემოთეული შემოწმებიდან რომელი გამოტოვეთ.