strongSwan send_cert: როდის იგზავნება IKE სერტიფიკატი

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

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

რას მართავს send_cert სინამდვილეში

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

ძველი ipsec.conf განლაგებები იყენებდნენ leftsendcert და rightsendcert, და ეს სახელები შეესაბამება ლოკალურ და დისტანციურ როლებს, და არა უშუალოდ swanctl-ს.

წაიკითხეთ ერთი მცდელობა კავშირის შეცვლამდე

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

მიმღების ნდობა ცალკე გადაწყვეტილებაა

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

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

შეცვალეთ გამგზავნი მხოლოდ მტკიცებულებებით

როცა ჟურნალი აჩვენებს, რომ სერტიფიკატი არასოდეს გაგზავნილა, ხოლო მიმღებმა ის ნამდვილად მოითხოვა, send_cert-ის მნიშვნელობა always ამ კავშირისთვის გამართლებული ცვლილებაა. გამოიყენეთ ის swanctl კონფიგურაციაში, თავიდან ჩატვირთეთ კავშირები და დაამყარეთ ახალი სესია ნაცვლად არსებული SA-ს ხელახალი გამოყენებისა. დაადასტურეთ, რომ სერტიფიკატის დატვირთვა ახლა ჩნდება და მიმღები მას განზრახული ღუზის მიმართ იღებს. თუ არაფერი იცვლება, შეცდომა მაინც ნდობის მხარეს იყო და გამგზავნის პარამეტრი მიზეზი არ ყოფილა.

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

დაკავშირებული სტატიები