firewalld-ის მსმენელის წესი და გადაგზავნის პოლიტიკა: რას აკეთებს თითოეული

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

ორი პოლიტიკა, ერთი გვირაბი

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

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

დაუშვით ნამდვილი გარე მსმენელი

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

უფლება მიეცით გაშიფრულ დანიშნულებას ცალკე

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

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

რატომ არის ინტერფეისის ნდობა არასწორი მოკლე გზა

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

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

შეამოწმეთ სამი რამ, მათ შორის ერთი უარყოფა

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

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