DH ფაილი თუ tls-auth გასაღები? OpenVPN-ის ორი ფაილის გარჩევა

ორი ფაილი, ორი დირექტივა და ჩვევა, ორივეს იმის სახელი ვუწოდოთ, რასაც ისინი აწყობენ. ასე ხვდება dh.pem tls-auth ხაზში და კლიენტი იშლება მოულოდნელი გასაღების ფორმატის შეტყობინებით. თქვენ წინაშე მდგარი გადაწყვეტილება არ არის, რომელი ფაილია უფრო ძლიერი. ის არის, რომელი როლი სჭირდება განლაგებას სინამდვილეში, და სამი პირობა წყვეტს ამას: რომელ გასაღების გაცვლას მოილაპარაკებს თქვენი TLS დასტა, გსურთ თუ არა საკონტროლო არხის ავთენტიფიკაცია საერთოდ, და უნდა დარჩეს თუ არა მასალა საიდუმლოდ.

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

წაიკითხეთ იარლიყი ფაილის სახელამდე

ფაილის პირველი ხაზი უფრო ინფორმაციულია, ვიდრე მისი სახელი, რადგან სახელი ადამიანური კონვენციაა, იარლიყს კი ინსტრუმენტი ქმნის. Diffie-Hellman პარამეტრებს აქვს PEM იარლიყი BEGIN DH PARAMETERS. OpenVPN-ის სტატიკური გასაღები სრულიად სხვა სტრუქტურაა, საკუთარი თავსართით და თექვსმეტობითი დატვირთვით.

გადარქმევა არაფერს გარდაქმნის. ta.key სახელის პარამეტრული ფაილი კვლავ პარამეტრებია, ხოლო dh.pem სახელის სტატიკური გასაღები კვლავ სტატიკური გასაღებია; გამყოფი კითხულობს შიგთავსს და უარყოფს შეუთანხმებლობას. შეამოწმეთ პროფილის რედაქტირებამდე:

head -n 1 dh.pem
head -n 1 ta.key

სამი პირობა, რომლებიც წყვეტს, რომელი ფაილი გჭირდებათ

პირველი პირობა გაცვლაა. სასრული ველის Diffie-Hellman ხელის ჩამორთმევას ჯგუფი სჭირდება და დირექტივა dh არის ადგილი, სადაც სერვერი მისთვის პარამეტრებს ასახელებს. ელიფსური მრუდის ხელის ჩამორთმევას ის ფაილი საერთოდ არ სჭირდება, რადგან მრუდი თავად პარამეტრთა სიმრავლეა. თუ თქვენი სერვერი მხოლოდ ECDHE კომპლექტებს აწარმოებს მოლაპარაკებას, DH ფაილი მკვდარი ტვირთია და არა დამატებითი სიმტკიცე.

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

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

შექმენით სწორი მასალა თითოეული როლისთვის

გამოიყენეთ ის ინსტრუმენტი, რომელიც დირექტივის მოსალოდნელ ფორმატს ქმნის, მათ შორის გარდაქმნის ნაცვლად. OpenVPN 2.6-ის საერთო გასაღებისთვის გენერატორის ტიპიზებული ფორმა დანიშნულებას ცხადად ასახელებს.

openvpn --genkey tls-auth ta.key

ეს ბრძანება ახალ საიდუმლო მასალას ქმნის; ის არ არემონტებს და არ ამოწმებს არსებულ გასაღებს, ხოლო ხელახლა გაშვება სხვა გასაღებს გაძლევთ, რომელიც სხვა მხარეებს არ აქვთ. მიღებული ფაილი გადააკოპირეთ მისთვის საჭირო მხარეებზე იმ არხით, რომელსაც ნებისმიერი საერთო საიდუმლოსთვის გამოიყენებდით, და მიმართულების კონვენცია თანმიმდევრულად შეინარჩუნეთ: tls-auth-ის შემთხვევაში ერთი მხარე იყენებს key-direction 0-ს, მეორე — key-direction 1-ს.

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

რას აკეთებს dh none და რას არა

dh none ნამდვილი დირექტივაა ვიწრო მნიშვნელობით: სასრული ველის პარამეტრული ფაილი არ ჩაიტვირთება, რადგან ხელის ჩამორთმევა ელიფსური მრუდის Diffie-Hellman-ს იყენებს. ის არ არის „DH ნაბიჯის გამოტოვების“ შემოკლება იმ გაგებით, რომ რამეს ასუსტებდეს, და ნამდვილად არ ეუბნება OpenVPN-ს, მიიღოს სხვა ფაილი შემცვლელად.

არასწორი წაკითხვიდან ორი შეცდომა გამომდინარეობს. პირველი — ვიფიქროთ, რომ dh none აუქმებს tls-auth-ის საჭიროებას, მაშინ როცა ორივე სხვადასხვა რამეს მართავს. მეორე — მხოლოდ მრუდის კონფიგურაციის გვერდით მოძველებული dh ხაზი შევინარჩუნოთ და შემდეგ ვიკითხოთ, რომელ ფაილს იყენებს სერვერი სინამდვილეში; თუ დირექტივა არსებობს, ფაილი იკითხება, და იქ გატეხილი გზა გაშვებას ამარცხებს იმ მიზეზით, რომელსაც არაფერი აკავშირებს მოსალაპარაკებელ გაცვლასთან.

თუ არასწორი ფაილი უკვე განლაგებულია

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

შემდეგ გამოყავით ის ორი შემთხვევა, რომელთა გაერთიანებასაც ადამიანები მიდრეკილნი არიან. DH პარამეტრული ფაილის გამოქვეყნება თითქმის უვნებელია, რადგან პარამეტრები დიზაინით საჯარო იყო. tls-auth გასაღების გამჟღავნება სხვა მოვლენაა: გასაღები საკონტროლო არხის პაკეტებს ავთენტიფიცირებს ყოველი მხარისთვის, რომელიც მას ინახავს, ამიტომ ჩანაცვლება მთელ განლაგებაზე უნდა შეთანხმდეს და არა ერთ ჰოსტზე გამოყენებულ იქნას.

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