L2TP: სასიკვდილო სიგნალი 15, NO_PROPOSAL_CHOSEN და დაკარგული modp1024

თქვენი კავშირი იკიდება, კლიენტი გადის და ეკრანზე ბოლო ხაზია death_handler: Fatal signal 15 received. ეს ხაზი წყვეტის შესახებ გვატყობინებს და არა მიზეზისა. ერთი ხაზით ზემოთ IPsec ჟურნალში თითქმის ყოველთვის არის NO_PROPOSAL_CHOSEN და წყვილი გაცვლის მე-2 ფაზაზე მიუთითებს, სადაც მხარეები ადარებენ დაშიფვრისა და ჰეშის არჩევანს და ჩერდებიან, როცა საერთო არაფერი აქვთ. ამ ეტაპზე საიდენტიფიკაციო მონაცემები ჯერ არ გაგზავნილა, ამიტომ პაროლის ხელახლა აკრეფა შედეგს ვერ შეცვლის.

Linux კლიენტზე ამ კვეთას ჩვეულებრივ ორი რამ აცარიელებს. ლოკალურმა დემონმა შეიძლება აღარ განახორციელოს პროფილის მოთხოვნილი Diffie-Hellman ჯგუფი, ან პროფილს 1-ლი ფაზის შეთავაზება მე-2 ფაზის ველში ჰქონდეს. ორივე კვალს ტოვებს ჟურნალში და არც ერთი ანგარიშის პრობლემა არ არის.

რას ამბობს ეს ორი შეტყობინება სინამდვილეში

IKE ეტაპებად მოლაპარაკებს. 1-ლი ფაზა დაცულ არხს აშენებს და საკუთარ ალგორითმებს ირჩევს; მე-2 ფაზა, შვილობილი SA, ტრაფიკს ცალკე ნაკრებით გადააქვს. NO_PROPOSAL_CHOSEN არის შეტყობინება, რომელსაც პასუხისმგებელი აბრუნებს, როცა შემოთავაზებული კომბინაციებიდან არც ერთი არ არის მისაღები, და ის INFORMATIONAL გაცვლის შიგნით [ HASH N(NO_PROP) ]-ის სახით ჩნდება.

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

წაიკითხეთ მოლაპარაკება სანამ საიდენტიფიკაციო მონაცემებს შეეხებით

გაზარდეთ ჟურნალის დონე იქ, სადაც დემონი წერს, შემდეგ ხელახლა დაუკავშირდით გამოსავალს დააკვირდებით. NetworkManager ჰოსტზე L2TP დანამატი ამ დონეს backend-ს გადასცემს და შეტყობინებები განაწილების მიხედვით journal-ში ან კლასიკურ syslog ფაილში ხვდება. ამათგან რომელიმე გაცვლას აჩვენებს: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' ან tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

pluto-ს ახსენებელი ხაზი libreswan-იდან მოდის, charon strongSwan-იდან და ორივე ერთსა და იმავე მდგომარეობას სხვადასხვა სიტყვით აღწერს. საძებნი ფორმა ის არის, რომელიც დაკარგულ ჯგუფს ასახელებს, მაგალითად algorithm 'modp1024' is not supported, რადგან ბუნდოვან ჩავარდნას კონკრეტულად აქცევს.

სად წავიდა modp1024

Diffie-Hellman-ის მე-2 ჯგუფი იმდენად სუსტია, რომ რამდენიმე განაწილებამ 3.30-დან libreswan-ში მისი კომპილაცია შეწყვიტა. მაშინ წლების წინ დაწერილი პროფილი, ან გეითვეის სახელმძღვანელოდან აღებული, რომელიც მხოლოდ aes128-sha1-modp1024-ს ჩამოთვლის, ლოკალურ დემონს ითხოვს ისეთ რამეს, რაც მას საერთოდ არ შეუძლია. NetworkManager-l2tp-ის უფრო ახალი აწყობები ამ შედეგს უფრო სავარაუდოს ხდის: 1.2.16-დან ისინი ნაკრებს Windows 10-ისა და iOS-ის სტილის შეთავაზებებით ცვლიან და modp1024-ს აგდებენ მაშინვე, როცა libreswan გამოვლინდება. მოპირდაპირე მხარე ხშირად უდანაშაულოა და კვლავ გთავაზობთ ზუსტად იმ ჯგუფს, რომელიც თქვენ დააყენეთ.

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

ორი შეკეთება სხვადასხვა გავლენით

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

მეორე შეკეთება ძველ გეითვეის მისაწვდომად ინახავს strongSwan-ის დაყენებით, რომლის პაკეტები უმეტეს განაწილებაში ჯერ კიდევ ახორციელებს მე-2 ჯგუფს. ეს დემონის შეცვლაა, ამიტომ ფასი აქვს: შეამოწმეთ, დამოკიდებულია თუ არა ჰოსტის სხვა გვირაბები libreswan-ის კონფიგურაციაზე სანამ წაშლით, და Fedora-ზე დაელოდეთ SELinux უარებს NetworkManager-სა და strongSwan დანამატს შორის. ეს უარები აუდიტის ჟურნალში ჩნდება და არა IKE კვალში, ამიტომ წარმატებული ინსტალაციის შემდეგ გვირაბი მაშინვე გატეხილად შეიძლება გამოჩნდეს. სწორი თანმიმდევრობაა ჯერ dnf install strongswan, შემდეგ rpm -e libreswan.

შეთავაზების შესაბამისი სტრიქონები და მათ გარშემო ხაფანგები

როცა ველები ხელით უნდა შეივსოს, 1-ლი და მე-2 ფაზები სხვადასხვა მნიშვნელობას იღებს. Meraki-ს სტილის მოპირდაპირე მხარის წინააღმდეგ მომუშავე ცნობილი წყვილი 1-ლ ფაზაში გთავაზობთ aes128-sha1-modp1024-ს, მის უკან 3des-sha1-modp1024-ს, ორივე დახურულია ძახილის ნიშნით, რომელიც ნაკრებს მკაცრს ხდის, ამიტომ მხოლოდ ის შეთავაზებები იგზავნება.

შემდეგ მე-2 ფაზა ვიწროვდება aes128-sha1-მდე და 3des-sha1-მდე იმავე მკაცრი ნიშნით და Diffie-Hellman-ის სუფიქსის გარეშე. -modp1024-ის მატარებელი მე-2 ფაზის ხაზი 1-ლი ფაზის მნიშვნელობაა არასწორ ველში და პასუხისმგებელი ყოველ ცდაზე უარყოფს მას. დააკოპირეთ ეს ხაზი მეორე პროფილში და მეორე პროფილიც იმავე გზით ვარდება, და ასე იქცევა ერთი ბეჭდვითი შეცდომა მთელი ფლოტის ინციდენტად.

სხვა ხარვეზები იმავე ამომხტარ ფანჯარას ატარებენ ისე, რომ შეთავაზების შეუთავსებლობა არ არიან. KDE-ზე L2TP ტიპი შეიძლება ჩამოთვლილი იყოს დანამატის დაყენებით, მაშინ როცა ყოველი კავშირი მაშინვე იღუპება, რადგან კავშირების რედაქტორი და გაშვების დროის დამხმარეები ცალკე პაკეტებად მოდის. ეკრანის გარეშე ჰოსტებს შეუძლიათ მომუშავე დესკტოპის პროფილის ხელახლა გამოყენება: დააკოპირეთ ის /etc/NetworkManager/system-connections/-დან, დააყენეთ რეჟიმი 600-ზე, შემდეგ გაუშვით nmcli con reload. ასწიეთ ის nmcli con up id work-l2tp-ით, რადგან შიშველი ფორმა UUID-ს ითხოვს, და წაშალეთ ნებისმიერი მოძველებული ifname ჩანაწერი, თორემ მენეჯერი პასუხობს Could not find source connection-ით, მაშინ როცა დანარჩენი ყველაფერი სწორია.

წინასწარ გაზიარებული გასაღები შეიძლება შეინახოს ღია ტექსტად ან როგორც 0s და შემდეგ base64; ორივე ფორმა მუშაობს, მაგრამ მნიშვნელობა გეითვეისთან ბაიტ-ბაიტ უნდა ემთხვეოდეს, მათ შორის ბოლოში იმ ჰარებით, რომლებიც მასთან ერთად დააკოპირეთ.