OpenVPN-ის "File exists" მარშრუტზე ფაილის პრობლემა არ არის

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

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

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

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

წაიკითხეთ არსებული მარშრუტი და არა მხოლოდ მისამართი

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

ოთხი მფლობელი, რომელიც პრეფიქსს შეიძლება ჰყავდეს

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

თითოეულ მფლობელს განსხვავებული შესწორება სჭირდება. დაკავშირებული მარშრუტი თქვენი არ არის წასაშლელად; მისი მოშორება შეიძლება ლოკალური წვდომა გატეხოს სანამ გვირაბი გამოსადეგი გახდება, და ბირთვი მას დააბრუნებს. მენეჯერის საკუთრებაში არსებული მარშრუტი უნდა შეიცვალოს ამ მენეჯერის მეშვეობით და არა ხელით ip route del-ით, რომელსაც შემდეგი ხელახალი დაკავშირება გააუქმებს.

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

block-local სხვა კითხვას პასუხობს

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

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

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

დახურეთ ციკლი: მოხსენით დუბლიკატი მის წყაროში

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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