რატომ აგებს OpenVPN მარშრუტი strongSwan-ის XFRM პოლიტიკასთან

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

ორი გადაწყვეტილება, არა ერთი

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

ფართო IPsec სელექტორი ჩვეულებრივი მიზეზია. პოლიტიკა, რომელიც იცავს 172.16.0.0/12-ს, ფარავს 172.20.8.0/24-საც, სადაც ადმინისტრატორს შესაძლოა OpenVPN გვირაბით სურდეს მოხვედრა. განზრახვა მხოლოდ მარშრუტიზაციის ცხრილში არსებობს და პოლიტიკების ბაზამ ამის შესახებ არასოდეს იცოდა.

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

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

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

წაიკითხეთ პოლიტიკაც, რომელიც ასევე მოქმედებს

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

ip -s xfrm policy
swanctl --list-sas

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

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

სამი ვარიანტი, როცა ორივე გზა კანონიერია

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

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

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

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

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

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

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