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

მენიუ და დემონი სხვადასხვა რამაა

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

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

წაიკითხეთ პაკეტი და არა ფაილი

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

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

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

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

შეასწორეთ გარემო სხვების დაუზიანებლად

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

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

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

მომდევნო შეცდომას ახალ ეტაპად მოეკიდეთ

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

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

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

დაკავშირებული სტატიები