Android IKEv2 ნდობის შეცდომა: გაგზავნეთ შუალედური CA და არა ფესვი
ტელეფონი უარყოფს კარიბჭეს, რადგან მიღებული ჯაჭვი ადრე წყდება. გადაწყვიტეთ: გაგზავნეთ შუალედური, შეასწორეთ იდენტობა ან შეცვალეთ გასაღების ტიპი.
ტელეფონი უარს ამბობს დაკავშირებაზე და ბეჭდავს No trusted RSA public key found for vpn.example.net, მაშინ როცა იგივე კარიბჭის სერტიფიკატი მუშაობს ლეპტოპიდან იმავე ქსელში. მაცდური ნაბიჯია სერტიფიკატის ხელახლა გაცემა. მანამდე დაადგინეთ, რომელი სამი ხარვეზიდან გაქვთ, რადგან მხოლოდ ერთი ეხება სერტიფიკატის შიგთავსს.
სამი ხარვეზი ერთი შეტყობინების უკან
Android აშენებს ჯაჭვს კარიბჭის სერტიფიკატიდან VPN პროფილში არჩეულ CA-მდე, შემდეგ ადარებს სერვერის სახელს პროფილს. შეტყობინება შედეგს აცხადებს და არა ეტაპს. ნდობის ხარვეზი ნიშნავს, რომ ჯაჭვი ვერ დასრულდა გაცვლაში გადაცემული სერტიფიკატებით; იდენტობის ხარვეზი — ჯაჭვი მოქმედია, მაგრამ სახელი არ ემთხვევა; ალგორითმის ხარვეზი — მოწყობილობა ან პროფილი არ იღებს გასაღების ტიპს ან ხელმოწერას.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
გადაწყვიტეთ მტკიცებულებებით და არა რემონტების რიგრიგობით ცდით. ერთი ცდა ჟურნალის დონე 2-ზე დემონზე გეტყვით, რომელ რიგში ხართ და ნაკლები ღირს, ვიდრე იმ სერტიფიკატის ხელახლა გაცემა, რომელიც არასდროს ყოფილა მცდარი.
ჯერ გადაწყვიტეთ: მოვიდა მთელი ჯაჭვი?
strongSwan აგზავნის ამ კავშირისთვის მომზადებულ სერტიფიკატს, ხოლო შუალედური სერტიფიკატები ცალკე რწმუნებებია. ისინი უნდა ჩაიტვირთოს CA სერტიფიკატებად მანამდე, სანამ დემონი ტვირთში ჩადებს, ამიტომ განლაგება, სადაც სერვერის სერტიფიკატი შუალედურითაა ხელმოწერილი, ფესვი ნდობის ღუზაა და შუალედური მხოლოდ CA-ის აწყობის საქაღალდეში ცხოვრობს, ზუსტად ამ ხარვეზს იძლევა: მავთულზე მხოლოდ ფოთოლია და ჯაჭვი ტელეფონზე ადრე მთავრდება.
შეამოწმეთ, რა აქვს დემონს swanctl --list-certs-ით swanctl განლაგებაზე, ან ipsec listcerts-ით ძველ starter-თან. შუალედური უნდა გამოჩნდეს როგორც CA სერტიფიკატი ფესვით ზემოთ. თუ არ არის, კლიენტის არც ერთი ვარიანტი არ დაეხმარება; თუ არის, გადადით შემდეგ კითხვაზე.
შემდეგ შეამოწმეთ, გაიგზავნება თუ არა. swanctl.conf-ის ცნობარი აღწერს send_cert-ს, რომლის ნაგულისხმევი ifasked სერტიფიკატებს აგზავნის მხოლოდ მაშინ, როცა პარტნიორმა ითხოვა, ხოლო always ყოველთვის აგზავნის. ძველი ეკვივალენტია leftsendcert=always ფაილში ipsec.conf. ეს პარამეტრი გაგზავნას მართავს და არა ხელმისაწვდომობას, ამიტომ ვერ აღადგენს იმ შუალედურს, რომელიც დემონს არასდროს ჩაუტვირთავს.
თუ ჯაჭვი მოკლეა, ჩატვირთეთ შუალედური იქ, სადაც დემონი ეძებს
მოათავსეთ შუალედური CA საქაღალდეში და არა ფოთლის გვერდით: /etc/ipsec.d/cacerts ipsec.conf-იანი განლაგებისთვის, /etc/swanctl/x509ca swanctl-ისთვის, ან ის გზა, რომელსაც თქვენი პაკეტი ცვლის. ხელახლა ჩატვირთეთ კონფიგურაცია და კვლავ ჩამოთვალეთ სერტიფიკატები. ზოგი ვერსია აგზავნის ნაკრებსაც ჯაჭვით ფოთლის ფაილში, მაგრამ CA საქაღალდე ვერსიებსა და პაკეტებს შორის გადატანადი განლაგებაა.
შეამოწმეთ კლიენტის მხრიდანაც. ტელეფონი მხოლოდ იმას ხედავს, რაც გაცვლამ გადაიტანა, ამიტომ დონე 2-ის დემონის ჟურნალმა უნდა აჩვენოს შუალედური გაგზავნილ სერტიფიკატებს შორის. თუ ჟურნალი აჩვენებს და ტელეფონი მაინც ვერ ახერხებს, ცხრილის სხვა რიგში ხართ და CA ფაილების შეცვლა შედეგს არ შეცვლის.
თუ ჯაჭვი სრულია, შეწყვიტეთ სერტიფიკატების რედაქტირება
იდენტობის ხარვეზი არის შეუთანხმებლობა VPN პროფილის სახელსა და სერტიფიკატის სახელს შორის. Android ადარებს თქვენ მიერ დაყენებულ სერვერის იდენტობას იმ სერტიფიკატს, რომელიც დაამოწმა, ამიტომ პროფილი, რომელიც მისამართზე მიუთითებს, სანამ სერტიფიკატი ჰოსტის სახელს ასახელებს, ან პროფილი ჰოსტის სახელით, რომელსაც სერტიფიკატი არ ფარავს, ჯაჭვის წარმატებული დადასტურების შემდეგ მარცხდება. შეასწორეთ არასწორი მხარე და შეინარჩუნეთ პროფილისა და სერტიფიკატის შესაბამისობა.
ალგორითმის ხარვეზი ვლინდება მოქმედი ჯაჭვითა და შესაბამისი სახელით. Android-ის ვერსიები განსხვავდება იმით, თუ რა გასაღების ტიპებსა და ხელმოწერის სქემებს იღებენ, და თავად პროფილის ტიპი ზღუდავს არჩევანს. თუ კარიბჭე ძველ ან უჩვეულო კომბინაციას იყენებს, შეადარეთ ის მოწყობილობის მხარდაჭერას, სანამ სერტიფიკატს დაზიანებულად ჩათვლით. ჟურნალი აჩვენებს, რომ ხელის ჩამორთმევა ნდობის შემთხვევაზე წინ მიდის, რაც ნიშანია, რომ ჯაჭვი აღარ არის პრობლემა.
ნუ დააყენებთ შუალედურს მომხმარებლის ფესვად ტელეფონზე
დაკარგული შუალედურის მომხმარებლის სერტიფიკატად დაყენება ტელეფონზე აქრობს გაფრთხილებას და ცვლის ტელეფონის ნდობის მოდელს ყოველი აპისთვის, რომელიც იღებს მომხმარებლის მიერ დაყენებულ ფესვებს. ის ასევე მალავს მიწოდების ხარვეზს, რომელიც შემდეგ კლიენტს მოხვდება, და კარიბჭეს ტოვებს, რომ ყოველ მომავალ მოწყობილობას არასრული ჯაჭვი გაუგზავნოს. გამძლე შესწორება სერვერზეა, ერთხელ, ყველა კლიენტისთვის.
ცალ-ცალკე შეინახეთ სამი გადაწყვეტილება ცვლილებების ჟურნალში: რომელი სერტიფიკატები გადაიცა, რომელი იდენტობა შედარდა და რომელი ალგორითმი შეთანხმდა. კარიბჭე, რომელიც ყოველთვის თავის სრულ ჯაჭვს აგზავნის, პროფილი, რომელიც სერტიფიკატს სწორად ასახელებს, და გასაღების ტიპი, რომელსაც ფლოტი მხარს უჭერს — სამი პატარა ფაქტია და ეს არის მთელი ეს ხარვეზი.