strongSwan ESP-in-UDP: როცა აღმოსაჩენი NAT არ არის

NAT-ის აღმოჩენა პოულობს მისამართების თარგმანს და არა firewall-ის პოლიტიკას. NAT-ის გარეშე საიტის კავშირს მაინც შეიძლება დასჭირდეს ESP-in-UDP-ის მკაფიო არჩევანი.

NAT-ის აღმოჩენა პასუხობს ერთ კითხვას: შეიცვალა თუ არა მისამართები ან პორტები გზაში? ის არ პასუხობს, უშვებს თუ არა firewall IP პროტოკოლ 50-ს. საიტის კარიბჭეები ყოველგვარი თარგმანის გარეშე მაინც შეიძლება იდგეს ისეთი პოლიტიკის უკან, რომელიც native ESP-ს აგდებს, და ეს მოთხოვნა უნდა დაკონფიგურდეს და არა აღმოაჩინოს. მექანიზმია ESP-in-UDP და ეს არის გადაწყვეტილება და არა თავისით გამოჩენილი სარეზერვო გზა.

აღმოჩენა მისამართებზე არითმეტიკაა და არა firewall-ის ზონდი

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

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

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

როგორ ცვლის encap გაცვლას

თანამედროვე strongSwan-ის განლაგებაში, რომელსაც მართავს swanctl.conf, კავშირზე encap = yes პარამეტრი გავლენას ახდენს NAT-ის აღმოჩენის გაცვლაზე, რათა ორივე მხარემ ESP-ისთვის UDP ინკაფსულაცია გამოიყენოს. დაცული პაკეტები შემდეგ UDP-ის შიგნით მოძრაობენ, ჩვეულებრივ პორტ 4500-ზე, და ორივე ბოლომ უნდა შეათანხმოს ეს განლაგება.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

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

გამოიყენეთ პარამეტრი, რომელიც თქვენს backend-ს ეკუთვნის

strongSwan-ს ორი კონფიგურაციის backend აქვს და გასაღები მათ შორის განსხვავდება. swanctl.conf კავშირი იღებს encap, ხოლო ძველი ipsec.conf კავშირი იღებს forceencaps. ერთი backend-ის საკვანძო სიტყვის მეორეში ჩადება ქმნის კონფიგურაციას, რომელიც უჩივლელად იტვირთება და არაფერს ცვლის, რაც შეცდომაზე უარესია.

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

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

შეამოწმეთ შეფუთული მონაცემები და არა მხოლოდ პორტი

დაიჭირეთ კარიბჭეზე, სანამ დაცული ტრაფიკი მიედინება, შემდეგ შეადარეთ ეს თავად strongSwan-ის ხედვას:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP გამოჩნდება როგორც IP პროტოკოლი 50 და საერთოდ არ ჰგავს UDP-ს. შეფუთული ESP გამოჩნდება როგორც UDP დატაგრამები 4500-ზე, რომელთა დატვირთვა IKE არ არის. IKE ტრაფიკი იმავე პორტზე ინკაპსულაციის მტკიცებულება არ არის, რადგან MOBIKE-ს შეუძლია IKE იქ გადაიტანოს, სანამ მონაცემთა გზა native რჩება, ამიტომ წაიკითხეთ დატვირთვა და არა პორტის ნომერი.

გაითვალისწინეთ გზის MTU-ც. გარსი ამატებს დამატებით ხარჯს და გზას, რომელიც native ESP-ს ატარებდა, შეიძლება დასჭირდეს კორექტირება პაკეტების გაზრდისას. საჭირო ICMP დამუშავება უკვე დიზაინის ნაწილი უნდა იყოს; ინკაპსულაცია ამ დამოკიდებულებას არ აქრობს.

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

დაკავშირებული სტატიები