tls-auth key-direction: 0 და 1 უნდა განსხვავდებოდეს, არა დაემთხვეს
tls-auth-ით ორივე ბოლოს საპირისპირო მიმართულება სჭირდება, 0 და 1, ან ორივემ უნდა გამოტოვოს პარამეტრი. იგივე რიცხვი ფარცხდება, და tls-crypt მას არასოდეს იყენებს.
გვირაბის ერთი მხარე საკონტროლო არხს ხელს აწერს გასაღების იმ სლოტით, რომელსაც მეორე მხარე არასოდეს ამოწმებს, და კავშირი იღუპება ავთენტიფიკაციის შეცდომით, სანამ ერთი სერტიფიკატიც კი გაიცვლება. ასე გამოიყურება მიმართულების შეუთანხმებლობა tls-auth-ში, და ის დეტერმინისტულია: იგივე ორი ფაილი ფარცხდება ყოველ ცდაზე, ნებისმიერი ქსელიდან. ჟურნალში არაფერი ასახელებს იმ პარამეტრს, რომელსაც ეძებთ, ამიტომ ხალხი თავიდან აშენებს გასაღებებს და ხელახლა გასცემს სერტიფიკატებს, რომლებიც არასოდეს ყოფილა გატეხილი. გამოსავალია ორივე ბოლოს შემავსებლად გახადოთ, ან ორივე ორმხრივად დატოვოთ, და არა შემოწმების შესუსტება.
ჩავარდნა სერტიფიკატებამდე ხდება
tls-auth-ით ორივე მხარე ერთსა და იმავე საერთო გასაღებს ფლობს და თითოეული მისგან წარმოებული ორი სლოტიდან ერთს იყენებს: ერთი სლოტი ხელს აწერს გამავალ საკონტროლო პაკეტებს, მეორე ამოწმებს შემომავალს. მიმართულება 0 და მიმართულება 1 ამ როლებს საპირისპირო რიგით ანიჭებს, ამიტომ წყვილი შემავსებელი უნდა იყოს, რომ HMAC შემოწმებები დაემთხვეს. როცა ერთ მხარეს დანიშვნა შებრუნდება, მიმღები ხელმოწერას არასწორ სლოტში ეძებს და პაკეტს უარყოფს. სესია იქ მთავრდება, ამიტომ შეცდომა პაკეტების ავთენტიფიკაციას ეხება და არა იმას, რასაც სერტიფიკატების საცავი წარმოქმნიდა.
დეტერმინიზმი დიაგნოსტიკისთვის მნიშვნელოვანია, რადგან დროის ან მარშრუტის პრობლემა სხვა კვალს ტოვებს: წყვეტილი გაწყვეტები, ერთი მიმართულების ჩავარდნა, ან სესია, რომელიც მხოლოდ გარკვეულ ქსელში იღუპება. მიმართულების შეუთანხმებლობა ყოველ ჯერზე პირველ ხელის ჩამორთმევაზე ფარცხდება, და ის იდენტურად ფარცხდება სხვა მანქანაზე იმავე ორი ფაილით. წაიკითხეთ ჟურნალი --verb 4-ზე და იპოვეთ პირველი უარყოფილი პაკეტი, და არა ბოლო ხაზი. თუ ეს უარყოფა რაიმე სერტიფიკატის გაცვლამდე ხდება, საერთო გასაღები და მისი მიმართულება არის ის ორი რამ, რისი შემოწმებაც ღირს.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
სად ცხოვრობს რიცხვი
OpenVPN 2.6-ის სახელმძღვანელო ორ ადგილს აღწერს მიმართულებისთვის: tls-auth-ის მეორე არგუმენტი, როცა გასაღები ცალკე ფაილშია, და დამოუკიდებელი key-direction ხაზი, როცა გასაღები პროფილშია ჩაშენებული. ორივე ერთსა და იმავე მნიშვნელობას აყენებს, ამიტომ პროფილმა ერთი ფორმა უნდა გამოიყენოს ან მეორე, არასოდეს ორივე. გამოტოვებაც არჩევანია, და ის ორივე მხარეს ორმხრივ განლაგებაში აყენებს, რომელიც მუშაობს, როცა არც ერთი მხარე არ ასახელებს მიმართულებას. ორი მხარე ერთი და იმავე რიცხვით ამ განლაგებაში არ არის: თითოეული ელოდება ერთ სლოტში ხელმოწერას და მეორეში შემოწმებას, და ორივე ამას ერთნაირად აკეთებს.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ჩაშენებული ფორმა ცალკე ხაზის დირექტივაა, და არა ატრიბუტი გასაღების ბლოკის გახსნის ტეგზე, და ამ ტეგზე არგუმენტის დამატება შეცდომაა, და არა მიმართულების ცვლილება. განლაგებასაც აქვს მნიშვნელობა: დირექტივა იმ ბლოკის გარეთ დგას, რომელსაც ეკუთვნის, ამიტომ ბლოკის შიგნით დაწერილი მნიშვნელობა გასაღების მასალად იკითხება. დააკოპირეთ ის განლაგება, რომელიც პროფილის დისტრიბუტორს ჰქონდა მხედველობაში, ნაცვლად წყვილის გამოგონებისა, რადგან ერთი სერვერის წინააღმდეგ მომუშავე პროფილი შესაძლოა უკვე ასახული იყოს მეორე მხარეს.
რას ტოვებს პარამეტრი ხელუხლებლად
ის არ შიფრავს აპლიკაციის ტრაფიკს. tls-auth HMAC-ს აყენებს საკონტროლო არხის პაკეტების გარშემო, ხოლო მონაცემთა არხი დაცულია ხელის ჩამორთმევის დროს შეთანხმებული სესიის გასაღებებით, ამიტომ გამტარობის ან შიფრის კითხვას მიმართულების რიცხვთან კავშირი არ აქვს. პარამეტრი მეორე შიფრაციის ფენასაც არ ამატებს, და სწორედ ეს ვარაუდი აგზავნის ხალხს უფრო გრძელი გასაღების საძებნელად.
ის არ ვრცელდება tls-crypt-ზე, საკონტროლო არხის სხვა მექანიზმი თავისი პარამეტრებითა და გასაღების დამუშავებით, და არაფერს ამბობს არც ერთი მხარის სერტიფიკატის იდენტობაზე. ამიტომ მომუშავე მიმართულების დამთხვევა მხოლოდ იმას ამტკიცებს, რომ ორივე ბოლო თანხმდება, როგორ მოახდინოს საკონტროლო არხის ავთენტიფიკაცია, და არა იმას, რომ ნდობის ჯაჭვი დადასტურებულია.
გაასწორეთ წყვილი, შემდეგ ხელახლა დაუკავშირდით
შეადარეთ ორი კონფიგურაცია სანამ რომელიმეს შეცვლით, რადგან უკვე სწორი მხარის რედაქტირება სამუშაოს აორმაგებს. ქვემოთ მოცემული grep გვიჩვენებს, თუ რომელ მექანიზმს ირჩევს თითოეული ფაილი; დეტალური გაშვება გვიჩვენებს, საერთოდ ავთენტიფიცირდა თუ არა საკონტროლო არხი. შეინახეთ ორივე გამოსავალი, რომ შემდეგი ცვლილება ცნობილ მდგომარეობას შევადაროთ.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
გადატვირთეთ ორივე მხარე ნებისმიერი ცვლილების შემდეგ, რადგან ეს პარამეტრები გაშვებისას ერთხელ იკითხება და ერთი მხარის გადატვირთვა წყვილს არათანმიმდევრულს ტოვებს ძველი სესიის მთელი სიცოცხლის განმავლობაში. თუ განლაგება ახლა მუშაობს მიმართულების გარეშე, პარამეტრის ერთ მხარეს დამატება ამრავლებს იმ ჩავარდნას, რომლითაც დაიწყეთ; ან ორივე დატოვეთ, ან ორივე დააყენეთ. შეცვალეთ ერთი ბოლო ერთდროულად და შეინახეთ წინა ფაილი, რომ რეგრესია ორწუთიანი დაბრუნება იყოს და არა ხელახალი აშენება.
ჩაწერეთ მექანიზმი, გასაღების ფაილი და მიმართულება თითოეული ბოლოსთვის განლაგების ჩანაწერებში, თორემ შემდეგი ადამიანი წაიკითხავს ორ მსგავს ფაილს და იფიქრებს, რომ რიცხვები ერთმანეთს უნდა დაემთხვეს. მიმართულება კოორდინაციის დეტალია და არა უსაფრთხოების გაუმჯობესება: ის ჰყოფს საკონტროლო არხის ორ მიმართულებას და მეტს არაფერს აკეთებს.