რას ამხელს ადგილობრივი სისტემური ჟურნალები VPN კავშირის შესახებ
ოპერაციული სისტემა აღრიცხავს სერვისების გაშვებას, ადაპტერის ცვლილებებსა და მარშრუტის წარუმატებლობას, რომლებსაც აპლიკაცია არასოდეს წერს. წაიკითხეთ ერთი ვიწრო ფანჯარა და დააკავშირეთ იგი.
ყოველი სამუშაო მაგიდა საკუთარ ჩანაწერს აწარმოებს იმის შესახებ, თუ რა გააკეთა VPN-მა, და აპლიკაციის ექსპორტი, როგორც წესი, მათ შორის ყველაზე არასრულია. სერვისის მენეჯერები აღნიშნავენ, როდის გაეშვა ერთეული, ბირთვი აღნიშნავს, როდის გამოჩნდა ინტერფეისი, და ქსელის სტეკი აღნიშნავს, როდის ვერ გამოყენდა მარშრუტები. ამ მექანიზმებიდან არცერთმა არ იცის, რა განიზრახა კლიენტმა, და კლიენტმა არ იცის, რა გააკეთა ბირთვმა მისი მოთხოვნით.
ასეთი ჩანაწერის იზოლირებულად წაკითხვა არასწორ დასკვნამდე მიგვიყვანს. წაიკითხეთ ორი, იმავე წუთიდან, და თანმიმდევრობა თვალსაჩინო ხდება.
სამი მექანიზმი სამი ლექსიკით
Linux-ზე systemd-ის ჟურნალი იჭერს ერთეულის სასიცოცხლო ციკლის შეტყობინებებს wg-quick@wg0-იდან ან NetworkManager-ის VPN დანამატიდან, და ბირთვის ბეჭდის ბუფერი ატარებს ინტერფეისისა და მარშრუტიზაციის შეტყობინებებს. Windows-ზე მოვლენათა ჟურნალი ყოფს ისტორიას სისტემურ, WLAN და დისტანციური წვდომის პროვაიდერებს შორის, თითოეული საკუთარი იდენტიფიკატორებით. macOS-ზე ერთიანი ჟურნალი ატარებს ქვესისტემით შეზღუდულ შეტყობინებებს, რომლებსაც გრაფიკული Console მხოლოდ ნაწილობრივ აჩვენებს.
ლექსიკები არ ითარგმნება. ერთი პლატფორმის მოვლენის იდენტიფიკატორი მეორეზე არაფერს ნიშნავს, და Windows-ის დიალოგის ეკრანის სურათი არაფერს ამტკიცებს Linux-ის ერთეულზე.
სამივეს საერთო არის დროის ნიშა, წყარო და სიმძიმე, და სწორედ ეს სამეული ხდის შესაძლებელს კლიენტის ჟურნალისა და ოპერაციული სისტემის ჩანაწერის დაკავშირებას. ხელმისაწვდომობაც განსხვავდება: კონტეინერი ჟურნალის გარეშე, შეკვეცილი Windows-ის იმიჯი ან აწყობის დროს დაქვეითებული ჟურნალის დონე შეიძლება მთელი ფენა დამალოს.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
რას ამტკიცებს დაკავშირებული ხაზი და რას არა
სერვისის გაშვების მოვლენა აღრიცხავს, რომ ადგილობრივ ერთეულს დაავალეს გაშვება და რომ იგი მაშინვე არ გავიდა. იგი არ აღრიცხავს დასრულებულ ხელის ჩამორთმევას, სწორ თანამოზიარე გასაღებს ან მოქმედ მარშრუტს. ამ ხაზის გვირაბის მტკიცებულებად მიჩნევა ამ ჟურნალების ყველაზე გავრცელებული არასწორი კითხვაა. ხაზი ამტკიცებს განზრახვასა და პროცესის მდგომარეობას, და სრულიად არაფერს ხელმისაწვდომობაზე.
გადაცემის მდგომარეობა ცალკე დაკვირვებაა, და იგი მარშრუტიზაციის ცხრილიდან მოდის და არა რომელიმე ჟურნალიდან.
ადაპტერის მოვლენამ შეიძლება ჩუმი წარუმატებლობა ახსნას: ინტერფეისი ავიდა, მისამართი მიენიჭა, და მარშრუტები არასოდეს დაყენდა, რადგან პოლიტიკის წესმა ისინი უარყო. ამ თანმიმდევრობაში ყოველი ხილული ხაზი ჯანსაღად გამოიყურება, მაშინ როცა არაფერი მარშრუტიზდება, და ამის დანახვის ერთადერთი გზა იმავე მომენტში ჟურნალის დროის ნიშების მარშრუტიზაციის ცხრილთან შედარებაა. შეინახეთ კლიენტის საკუთარი მოვლენათა რიგი ორივეს გვერდით, რადგან კლიენტი ერთადერთი წყაროა, რომელმაც იცის, რა მოითხოვა. ორი ფაქტი, რომელიც ერთად გჭირდებათ, თითქმის არასოდეს ჩნდება ერთ ხაზზე.
მოგვიანებით ხელახალი დაკავშირება გადაფარავს ამ სურათის საინტერესო ნაწილს, ამიტომ ფანჯარა დაიჭირეთ პირველ წარუმატებლობაზე და არა სამი ცდის შემდეგ.
დააკავშირეთ ვიწრო ფანჯარა
ჩაწერეთ ცდის დრო მისი დროის სარტყლით, შემდეგ ამოიღეთ მის ირგვლივ არსებული რამდენიმე წუთი. ფანჯარაში პირველი შეცდომა თითქმის ყოველთვის წინ უსწრებს იმ გათიშვის ხაზს, რომელსაც მხარდაჭერის ბილეთები ციტირებენ.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
თითოეული ბრძანება კითხვის სხვადასხვა ნაწილს პასუხობს: პირველი იძლევა სასიცოცხლო ციკლს, მეორე — გადაცემის მდგომარეობას, მესამე — macOS-ის ქსელურ ქვესისტემას. Windows-ზე გაფილტრეთ სისტემური ჟურნალი პროვაიდერის სახელით, მთელი არხის გადახვევის ნაცვლად, და გაიტანეთ მხოლოდ შესაბამისი მოვლენები.
შეინახეთ ამონაწერი საკმარისად პატარა, რომ მკითხველმა შეძლოს მისი თვალყურის დევნება. ოცწუთიანი ფანჯარა ოთხი შესაბამისი მოვლენით ასაბუთებს დასკვნას; მთელი დღის ექსპორტი ათასობით ხაზით არაფერს ასაბუთებს.
სად წყდება ეს ჩანაწერები
ადგილობრივი ჩანაწერები აღწერენ მოწყობილობას და არა გზას. ისინი ვერ აჩვენებენ, რა შეინახა პროვაიდერმა, დაუკავშირდა თუ არა სესია ანგარიშს, ან რა დაინახა დანიშნულმა. პროვაიდერის განცხადება, რომ ჟურნალებს არ ინახავს, არაფერს ამბობს თქვენი ლეპტოპის ოპერაციულ სისტემაზე, და ადგილობრივი მოვლენა არაფერს ამტკიცებს პროვაიდერის ისტორიულ ჩანაწერებზე.
ისინი უფრო მეტ პირად მონაცემსაც ატარებენ, ვიდრე მოსალოდნელია: მომხმარებლის სახელები, ჰოსტის სახელები, ჩამონტაჟების გზები და მოწყობილობის იდენტიფიკატორები ჩნდება ჩვეულებრივ სისტემურ შეტყობინებებში მაშინაც, როცა დათვალიერების შიგთავსი არ არსებობს. წაშალეთ ისინი სანამ რაიმეს ბილეთს მიამაგრებთ, და ორიგინალი შეინახეთ ჩვეულებრივი წვდომის კონტროლის ქვეშ.
მართულ მოწყობილობაზე ორგანიზაციული ჟურნალის გასუფთავების მცდელობის ნაცვლად მოითხოვეთ შესაბამისი ამონაწერი IT-სგან. დიაგნოსტიკური მიზანია ერთი ვიწრო კითხვა, რომელსაც ორი წყარო პასუხობს, და არა მანქანის სრული ისტორია.