journalctl VPN-ის ჟურნალებისთვის: რომელი ერთეული ფლობს კავშირს?

დაიწყეთ იმ systemd ერთეულით, რომელიც ნამდვილად ფლობს VPN კავშირს და არა იმ ჟურნალის ბრძანებით, რომელიც გახსოვთ. პირდაპირი OpenVPN სერვისი, wg-quick ერთეული და NetworkManager პროფილი თავიანთ სასარგებლო შეტყობინებებს სხვადასხვა ერთეულში ათავსებენ, ხოლო არასწორ ერთეულზე გაკეთებული მოთხოვნა ცარიელ შედეგს იძლევა, რომელიც სიჩუმეს ჰგავს. შეადარეთ სამი ჩვეულებრივი მფლობელი, შევიწროვეთ ფანჯარა, შემდეგ წაიკითხეთ ეტაპები რიგითობით.

შეადარეთ სამი ჩვეულებრივი მფლობელი

OpenVPN კლიენტის სერვისი ჩვეულებრივ პროფილის სახელობის ინსტანს ერთეულია, მაგალითად [email protected]. მისი შეტყობინებები მოიცავს კონფიგურაციის გზას, ოპციების ანალიზს, TLS ხელის ჩამორთმევას და მარშრუტის ინსტალაციას, რომელსაც კლიენტი აკეთებს.

wg-quick ერთეული კონსტრუქციით უფრო ჩუმია. ინტერფეისის კონფიგურაცია გაშვებისას ხდება, ხელის ჩამორთმევას ბირთვი ამუშავებს, ხოლო რუტინული გასაღების განახლებები ნაგულისხმევად არ იწერება, ამიტომ wg show ხშირად უფრო საინფორმაციოა, ვიდრე ჟურნალი. ეს განსხვავება მნიშვნელოვანია, როცა ადარებთ პროტოკოლს, რომელიც მოლაპარაკებას წერს, იმასთან, რომელიც ამას არ აკეთებს.

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

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

ჰკითხეთ იმ ერთეულს, რომელიც ამოიცანით, და შეზღუდეთ დრო იმ მცდელობით, რომელსაც იკვლევთ. ერთი დღე ჩვეულებრივ საკმარისია, ხოლო მოკლე ფანჯარა უკეთესია, როცა მანქანა ხშირად ხელახლა უკავშირდება.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

წაიკითხეთ პირველი წარუმატებელი ეტაპი

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

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

ნუ აურევთ წარუმატებელ სერვისს ხელით გაშვებულ კლიენტს

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

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

გააზიარეთ ამონაწერი და არა ექსპორტი

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

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