რატომ ტოვებს თქვენი VPN ინტერფეისი მუდამ თავის firewalld ზონას

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

ზონა ძლებს მანამ, სანამ ინტერფეისი ხელახლა შეიქმნება

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

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

სანამ რაიმეს შეცვლით, გაარკვიეთ რომელი კომპონენტი ანიჭებს ზონას.

წაიკითხეთ სამი რამ, სანამ რაიმეს შეცვლით

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

ყოველ საფეხურზე ჩაწერეთ მოწყობილობის ნამდვილი სახელიც, რადგან გვირაბი, რომელიც დღეს tun0-ზე ჯდება, ხვალ tun1-ზე შეიძლება დაჯდეს.

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

როცა NetworkManager ფლობს კავშირს

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

ამ თვისების შეცვლამ შეიძლება დაუყოვნებლივ იმოქმედოს აქტიურ კავშირზე.

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

როცა firewalld ფლობს მიბმას

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

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

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

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

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

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

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

ჩაწერეთ მფლობელი, მნიშვნელობა და მოსალოდნელი შედეგი runbook-ში, და შემდეგი ხელახალი მინიჭება ახსნადი იქნება.