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

მშობლიურ VPN-ს, Tunnelblick-ს და მომწოდებლის საკუთარ კლიენტს შეიძლება განსხვავებული ჟურნალის მფლობელები ჰყავდეთ. დაიწყეთ კლიენტის მხარდაჭერილი ჟურნალის ხედით, როცა ის გვთავაზობს მას, და მიმართეთ Console-ს, როცა საჭიროა სისტემის ან მომწოდებლის მოვლენები მცდელობის გარშემო.

აირჩიეთ კლიენტი, რომელიც ნამდვილად ჩავარდა

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

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

დაიწყეთ ცოცხალი ხედი მცდელობამდე

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

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

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

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

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

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

შეინახეთ საკმარისი კონტექსტი ერთ კითხვაზე პასუხისთვის

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

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

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

გააზიარეთ ყველაზე პატარა სასარგებლო ამონაკრები

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

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

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