L2TP-ის გამართვის ჟურნალი ცარიელია? შეცდომა სავარაუდოდ journal-შია

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

ოთხი პროცესი, ჟურნალის ორი დანიშნულება

კავშირი იწყება IPsec-ით, რომელიც ინსტალაციის მიხედვით libreswan ან strongSwan არის. შემდეგ L2TP დემონი, ტრადიციულად xl2tpd და ზოგიერთ აწყობაში kl2tpd, გვირაბს მართავს. ბოლოს pppd მის შიგნით ავთენტიფიკაციასა და მისამართებს უწევს.

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

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

შეაგროვეთ ერთი მცდელობა, შემდეგ წაიკითხეთ რიგი

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

ეს ბრძანებები ირჩევენ მიმდინარე ჩატვირთვის მონაწილე პროცესებს და ღირს პლაგინის გზის დადასტურება თქვენს დისტრიბუტივში:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

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

შემდეგ ნაბიჯს სამი პირობა განსაზღვრავს

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

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

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

ასევე ღირს დაადასტუროთ, რომელი IPsec-ის backend არის დაყენებული, სანამ გამართვის პარამეტრს შეეხებით. strongSwan-ისთვის დაწერილი ჟურნალირების ოფცია არაფერს აკეთებს, როცა libreswan მუშაობს, და კავშირი გააგრძელებს მარცხს იმავე ადგილას, სანამ თქვენ ისეთ ფაილს არ არედაქტირებთ, რომელსაც არავინ კითხულობს.

გამართვის რეჟიმი ფაილებს ტოვებს

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

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

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

შემდეგ აღადგინეთ ნორმალური დამხმარე პროგრამა

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

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

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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