Mac-ის VPN ერთხელ უკავშირდება და შემდეგ დრო იწურება: გაასუფთავეთ IKE დემონი

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

macOS-ზე ეს რაღაც ჩვეულებრივ IKE დემონია.

ნიმუში: ერთი კავშირი, შემდეგ დროის ამოწურვა

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

ეს ავიწროებს გამოძიებას სანამ ერთ მანიფესტსაც გახსნით. კითხვა ხდება, რომელი პროცესი ფლობს IKE პორტს და რას ფიქრობს, რომ აკეთებს.

ორი დემონი, ერთი პორტი

სისტემა უშვებს racoon როდესაც კავშირი IKE ვერსია 1-ზე საუბრობს. მიმდინარე გამოშვებები ასევე მოაქვთ iked IKEv2-ისა და უფრო ახალი IPsec სტეკისთვის. ორივეს შეუძლია UDP 500 და UDP 4500-ის დაკავება, და ორივეს შეუძლია ნახევრადღია უსაფრთხოების ასოციაციის შენახვა მას შემდეგ, რაც კავშირის ცდა პაროლის მოთხოვნისას გაუქმდა ან ქსელის ცვლილებით შეწყდა.

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

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

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

წაიკითხეთ გამოტანილი, როგორც ორი ფაქტი: რომელი პროცესი იკავებს პორტს, და არის თუ არა ერთზე მეტი. ერთი და იმავე სოკეტისთვის მოასპარეზე ორი IKE დემონი ხსნის ბევრ წყვეტილ ქცევას, რომელიც არასტაბილურ სერვერს ჰგავს.

გადატვირთეთ დავალება და არა პროცესი

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

თუ launchd-ს დავალების ჩანაწერი არ აქვს, პროცესის სახელით მოკვლა მაინც აიძულებს ახალ მოლაპარაკებას შემდეგ ცდაზე. ტესტი ორივე შემთხვევაში ერთია: არცერთ პროცესს არ უნდა ეკავოს პორტი, როცა ხელახლა ცდილობთ დაკავშირებას. დაადასტურეთ ეს იმავე ბრძანებით lsof იმის ნაცვლად, რომ ჩათვალოთ, რომ გადატვირთვამ იმუშავა.

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

როდესაც სერვერია ის, ვინც უარყოფს

ყოველი მეორე კავშირი ლოკალურად არ ვარდება. სერვერს შეუძლია ახალი შესვლა უარყოს გათიშვის შემდეგ ფიქსირებული ფანჯრის განმავლობაში, და კლიენტის დროის ამოწურვა იდენტურად გამოიყურება ჩარჩენილ დემონთან. გამმიჯნავი იაფია: თუ დემონის გადატვირთვა არ ეხმარება, მაგრამ სხვა ანგარიში მაშინვე უკავშირდება, ფანჯარა სერვერის მხარესაა და Mac არასოდეს ყოფილა პრობლემა.

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

წაიკითხეთ პარტნიორის მანიფესტი სანამ კლიენტს კვლავ შეცვლით. უარყოფა, პოლიტიკის შეუსაბამობა და ჩუმი ჩამოგდება სამი განსხვავებული მიზეზია, რომლებიც Mac-ის ეკრანზე ყველა „უკავშირდება“-ს ჰგავს.

ძველი კლიენტები და 64-ბიტიანი ბირთვი

ძველი Cisco IPSec კლიენტი ტვირთავს ბირთვის გაფართოებას, რომელიც 32-ბიტიანი და PowerPC სისტემებისთვისაა აწყობილი. 64-ბიტიან ბირთვში ჩატვირთულ Mac-ზე ეს გაფართოება ვერ ჩაიტვირთება, და კლიენტი ადრევე ვარდება შეცდომა 51-ით, რადგან VPN ქვესისტემას საერთოდ ვერ აღწევს. დემონის რამდენჯერ გადატვირთვაც არ უნდა მოხდეს, არასწორი არქიტექტურის ბირთვის გაფართოებას არ ასწორებს.

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

• ერთხელ გაამრავლეთ და შემდეგ, პროფილზე შეხებამდე, შეამოწმეთ რომელი დემონი ფლობს UDP 500-ს.
• წაიკითხეთ პირველი წარუმატებლობა 1-ელი ფაზის შემდეგ: გადაცემის შეცდომა ლოკალურ სოკეტზე მიუთითებს.
• გადატვირთეთ launchd დავალება და არა მხოლოდ პროცესი, და დაადასტურეთ, რომ პორტი თავისუფალია.
• სცადეთ მეორე ანგარიში, რომ გამოყოთ სერვერის მხარის ხელახალი ავთენტიფიკაციის ფანჯარა კლიენტის ხარვეზისგან.
• ჩაწერეთ ბირთვის არქიტექტურა სანამ კლიენტს დაადანაშაულებთ.

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