NO_PROPOSAL_CHOSEN L2TP-ზე? ჯერ კარიბჭე სკანირეთ

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

რას გამორიცხავს ეს შეტყობინება

უარი ხდება მთავარ რეჟიმში, ნებისმიერ L2TP ან PPP გაცვლამდე, ამიტომ გვირაბი და მომხმარებლების ბაზა არ გამოკითხულა. 1-ლი ფაზა აწარმოებს მოლაპარაკებას დაშიფვრაზე, მთლიანობასა და Diffie-Hellman ჯგუფზე. მე-2 ფაზა აწარმოებს მოლაპარაკებას მონაცემების ESP წინადადებაზე. 1-ლი ფაზის ჩავარდნას ვერ გამოასწორებს მე-2 ფაზის PFS პარამეტრის შეცვლა, და დასრულებული IKE ასოციაცია არ ამტკიცებს, რომ ESP წინადადება შეესაბამება.

სინტაქსის რედაქტირებამდე ჩაწერეთ backend: ipsec --version. libreswan და strongSwan ერთი და იმავე ალგორითმებისთვის წინადადების სხვადასხვა ჩანაწერს იღებენ.

შემდეგ წაიკითხეთ უარი კონტექსტში ამ ბრძანებით: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

სკანირეთ კარიბჭე მისი ტრანსფორმაციების ნაკრებისთვის

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

ძველი მოწყობილობები ხშირად სთავაზობენ 3DES-ს, SHA1-ს და MODP1024-ს, რადგან ეს იყო ნაგულისხმევი პარამეტრები პროდუქტის გაგზავნისას და არავის გადაუხედავს მათთვის. შეინახეთ სკანირების ნედლი შედეგი, რადგან ეს არის ერთადერთი ჩანაწერი იმის შესახებ, თუ რა შესთავაზა მოწინააღმდეგე მხარემ იმ დღეს. თუ ეს არის ხელმისაწვდომი ყველაზე ძლიერი გადაფარვა, სწორი ესკალაცია კარიბჭის მფლობელისკენაა და არა კლიენტის კონფიგურაციისკენ, რომელიც ყველასთვის სუსტ კრიპტოგრაფიას ისევ რთავს.

შეუთავსეთ გადაფარვა უსაფრთხოების გამორთვის გარეშე

შეიტანეთ მხოლოდ ის ტრანსფორმაციები, რომლებიც გვხვდება სკანშიც და თქვენს პოლიტიკაშიც. ქვემოთ მოცემული მაგალითი ასახავს კარიბჭეს, რომელიც 1-ლ ფაზაში სთავაზობს 3DES-ს, SHA1-ს და MODP1024-ს. გაითვალისწინეთ backend-ის დათქმა: libreswan 4.x არ აკომპილირებს modp1024 ჯგუფს, ამიტომ ეს ეხება strongSwan-ს ან DH2-ის მხარდაჭერის მქონე libreswan-ის აწყობას. გადაამოწმეთ ვერსია, სანამ დაასკვნით, რომ კლიენტი გატეხილია.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

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

NetworkManager-l2tp იწყებს საკუთარ xl2tpd ინსტანსს. თუ სისტემურ სერვისს უკვე უკავია UDP 1701, კლიენტი გადადის დროებით წყარო პორტზე, რასაც RFC 3193 უშვებს და ზოგიერთი სერვერი ჩუმად აგდებს. შეამოწმეთ socket-ის მფლობელი შემდეგ ცდამდე.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

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

და ბოლოს, შეამოწმეთ, საიდან მოვიდა რჩევა. ipsec.conf IKEv1 XAuth-ისთვის დაწერილი ფაილი აღწერს სხვა ტიპის VPN-ს და მისი წინადადება არ არის ერთადერთი მწკრივი, რომელიც L2TP პროფილში არასწორი იქნება. ჩაწერეთ შეყვანილი ტრანსფორმაციების ნაკრები პროფილის გვერდით, რომ შემდეგმა ადამიანმა არ გაიმეოროს შემოწმება.