L2TP NO_PROPOSAL_CHOSEN: რომელი ეტაპი ჩავარდა სინამდვილეში?
შეტყობინება ამბობს, რომ წინადადება უარყვეს, მაგრამ არა რომელი. ეტაპის გასარკვევად წაიკითხეთ backend-ის ჟურნალი, შემდეგ შეადარეთ კრებულები იმას, ვინც კარიბჭეს მართავს.
NO_PROPOSAL_CHOSEN მოდის მანამ, სანამ PPP-ის რომელიმე მომხმარებლის სახელი შემოწმდება, რაც სასარგებლო ფაქტია და ამავე დროს მიზეზი, რის გამოც შეტყობინება შეცდომაში შეჰყავს. ის იტყობინება, რომ ერთმა მხარემ წინადადება უარყო; არ იტყობინება, რომელი პარამეტრი არ დაემთხვა, და არაფერს ამბობს იმაზე, მოხდა უარყოფა IKE-ის ასოციაციის აგების დროს თუ მოგვიანებით, ტრაფიკის დაცვის შესახებ მოლაპარაკებისას. ამ ორი შესაძლებლობის უკან ორი განსხვავებული შესწორება დგას და მათგან მხოლოდ ერთი ეხება PFS-ის მოსანიშნ უჯრას, რომელსაც ხალხი პირველად მიმართავს.
ერთი შეტყობინება, წინადადებათა ორი კრებული
IKEv1 L2TP/IPsec განლაგებაში ზედიზედ ორი მოლაპარაკებაა. ეტაპი 1 აშენებს IKE-ის უსაფრთხოების ასოციაციას დაშიფვრის ალგორითმისგან, მთლიანობის ალგორითმისგან და Diffie-Hellman ჯგუფისგან. შემდეგ ეტაპი 2 აწარმოებს მოლაპარაკებას იმაზე, თუ როგორ იცავს თავს ტრაფიკი, და PFS-ის მოთხოვნა სწორედ იმ მეორე საუბარს ეკუთვნის.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
ვინაიდან ეტაპები თანმიმდევრულია, წარუმატებლობის ადგილი გეუბნებათ, რომელი სია უნდა შევადაროთ. შეტყობინების მთელი დიაგნოსტიკური ღირებულება სწორედ ამაშია და ღირს მისი ამოღება რომელიმე პარამეტრზე ხელის დადებამდე.
რატომ ვერ შეაკეთებს PFS-ის მოსანიშნი უჯრა ეტაპ 1-ს
PFS-ის გამორთვა ცვლის ეტაპი 2-ის თვისებას. თუ მხარეები ეტაპ 1-ზე არასოდეს შეთანხმდნენ, ESP-ის საუბარი საერთოდ არ ხდება, ამიტომ მოსანიშნ უჯრას უარყოფაზე არანაირი გავლენა არ აქვს და სწორედ ამიტომ იძლევა მისი გადართვა იმავე შეცდომას სხვა დროის ნიშნით.
საპირისპირო შეცდომაც თანაბრად გავრცელებულია. წარმატებული IKE-ის ასოციაცია არ ამტკიცებს, რომ ESP-ის წინადადება მისაღებია, და ნამდვილად არ ამტკიცებს, რომ ეტაპი 2-ის ჯგუფი ემთხვევა. დადგენილ სამართავ გვირაბს განიხილეთ მხოლოდ ეტაპ 1-ის მტკიცებულებად. ადამიანები მწვანე ხაზს კითხულობენ როგორც «გვირაბი მუშაობს», შემდეგ საათს ხარჯავენ არასწორ ეტაპზე, რადგან ვერაფერმა არ უთხრა მათ, რომ მეორე მოლაპარაკება არ დაწყებულიყო.
წაიკითხეთ ჟურნალი ალგორითმების არჩევამდე
შეაგროვეთ უარყოფამდე უშუალოდ წინა შეტყობინებები იმ backend-იდან, რომელიც ნამდვილად ემსახურება კავშირს, და დააკავშირეთ ისინი იმავე მცდელობასთან. ამ დაკავშირების გარეშე თქვენ სხვა კავშირის ისტორიას კითხულობთ და მისგან ასკვნით.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanამ სტრიქონებიდან უპასუხეთ ორ კითხვას: დამყარდა თუ არა ეტაპ 1-ის ასოციაცია და რომელი გაცვლა ჩავარდა. ეს ორი პასუხი ძებნას ერთ ატრიბუტთა სიამდე ავიწროებს. შიშველი შეტყობინება გარემომცველი კონტექსტის გარეშე ამას ვერ შეძლებს, რამდენადაც მაცდურია ფორუმის თემიდან წინადადების გამოცდა. სამუშაო სტრიქონის კოპირება სხვა backend-ის მქონე მანქანიდან ჩვეულებრივ ერთ უარყოფას ცვლის მეორეთი, ცოტა მოგვიანებით.
Backend-ის სინტაქსი არ მოგზაურობს
ჩაწერეთ NetworkManager-l2tp-ის ვერსია და IPsec backend-ის ვერსია სანამ რამეს შეადარებთ. Libreswan და strongSwan არ იზიარებენ წინადადებების სინტაქსს ან იდენტურ ალგორითმთა კრებულებს, ამიტომ ერთში მომუშავე სტრიქონი მეორეში სინტაქსური შეცდომაა. დაყენებულმა backend-მა შეიძლება პოლიტიკის მიხედვით IKEv1-იც უარყოს და მაშინ არცერთი წინადადება არასოდეს მიღებული იქნება.
პროექტის README აღწერს backend-ებს შორის ამ განსხვავებებს და ეტაპი 1-ისა და ეტაპი 2-ის ველებს ცალ-ცალკე ინახავს. წაიკითხეთ ის როგორც სტრუქტურის დოკუმენტი, და არა როგორც მოწვევა ყოველი ისტორიული შიფრისა და სუსტი ჯგუფის ჩასართავად, რადგან კავშირი, რომელიც მხოლოდ ასე წარმატდება, ის კავშირი არ არის, რომლის აშენებაც გთხოვეს.
შეთანხმდით კრებულზე, შემდეგ გადაამოწმეთ ეტაპები
ჰკითხეთ კარიბჭის ოპერატორს, რომელი IKE და ESP კრებულებია მხარდაჭერილი და დამტკიცებული, შემდეგ შეადარეთ ეს პასუხი კლიენტის ფაქტობრივ წინადადებებს და არა მის კონფიგურაციის ფაილს. თუ უთანხმოება კონკრეტულად ეტაპი 2-ის PFS-ს ეხება, შეჩერდით მხარდაჭერილ ჯგუფზე ან ცალსახად დამტკიცებულ PFS-ის გარეშე პოლიტიკაზე. ნუ გამოიტანთ პოლიტიკას შეცდომის სახელიდან.
როცა ერთადერთი გადაფარვა მოითხოვს კრიპტოგრაფიას, რომელსაც ორგანიზაცია აღარ იღებს, გადაწყვეტილება კარიბჭეს ან პროტოკოლის მიგრაციას ეკუთვნის. კლიენტის სტრიქონის გაფართოება მანამ, სანამ რაღაც იმოლაპარაკებს, ცნობილი სისუსტის გვერდით მწვანე ნიშნით მიწოდების ხერხია.
რეალური შეუსაბამობის გასწორების შემდეგ დაადასტურეთ IPsec-ის დამყარება სანამ L2TP-სა და PPP-ს გამოიკვლევთ, და ნებისმიერი შემდგომი ავთენტიფიკაციის უარყოფა მომდევნო ეტაპს მიაკუთვნეთ. შემდეგ სცადეთ განახლება დამტკიცებულ სატესტო პროცესში, რადგან პირველი ასოციაციის დამყარება არაფერს ამბობს მისი სიცოცხლის დანარჩენ ნაწილზე.