რატომ OpenVPN კლიენტის ბლოკირების წესი არასდროს ხვდება FORWARD-ში

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

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

ორი გზა, რომლითაც თანამონაწილის პაკეტს შეუძლია გაიაროს

როცა შიდა გადაცემის ოფცია გამორთულია, კლიენტ A-ს პაკეტი ტუნელის ინტერფეისზე მოდის დანიშნულებით კლიენტ B-ის გამოყოფილი მისამართის შიგნით. სერვერის მარშრუტიზაციის ცხრილი მას იმავე ტუნელის ინტერფეისით უკან აგზავნის, რადგან B-ის მისამართამდე მარშრუტი სერვერს ეკუთვნის. ეს ჰოსტში შემავალი და გამომავალი ნაკადია, და მას IPv4 გადაცემის გზა აფასებს.

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

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

როცა მრიცხველი არასდროს იძვრება

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

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

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

საზღვრის არჩევა, რომელსაც შეუძლია გაფილტვრა

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

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

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

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

იზოლაციის ტესტირება წესის ნდობის ნაცვლად

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

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

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