strongSwan-იდან AWS Site-to-Site-მდე: რატომ არ ირჩევს Child SA არაფერს

IKE გვირაბი შეიძლება აწეული იყოს, სანამ შვილობილი ასოციაცია თქვენს ქვექსელებს გამორიცხავს. ჯერ შეადარეთ AWS-ის ლოკალური და დისტანციური CIDR leftsubnet-სა და rightsubnet-ს.

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

თარგმნეთ AWS-ის სახელები strongSwan-ის ტერმინებში

AWS აღწერს კავშირს კლიენტის მხრიდან: კლიენტის კარიბჭის მისამართი და ლოკალური CIDR თქვენია, ხოლო დისტანციური CIDR VPC-ს ეკუთვნის. strongSwan ორ კიდეს left და right უწოდებს, თქვენი პრეფიქსი leftsubnet-შია, VPC-ის პრეფიქსი კი rightsubnet-ში. ერთი წყვილის შებრუნება ქმნის გვირაბს, რომელიც არასწორ ტრაფიკზე მოლაპარაკებას აწარმოებს და ირჩევს მას.

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

აქ არსებული შეუსაბამობა მარშრუტიზაციის ჩავარდნას ჰგავს და არც არის.

დაამაგრეთ მისამართი, რომელსაც AWS რეალურად ხედავს

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

conn %default
    local_addrs = 203.0.113.10

strongSwan-ში local_addrs ირჩევს წყაროს მისამართს IKE-სთვის, ხოლო ძველი OpenSwan კონფიგურაციები იგივე იდეას left-ად წერენ. მიმართეთ ის ინტერფეისს, რომელსაც საჯარო მისამართი აქვს, შემდეგ თავად NAT მოწყობილობაზე შეამოწმეთ, რომ UDP 500 და 4500 აღწევს ამ ჰოსტამდე, რადგან წინა მარშრუტიზატორიდან დარჩენილი წესი მათ ჩუმად ყრის. სწორი სელექტორების წყვილი არასწორი წყაროს მისამართით მაინც ვერ მუშაობს, და ჟურნალი შეთავაზებას დაადანაშაულებს. სწორედ ეს შეცდომაში შეყვანაა მიზეზი, რომ წყაროს მისამართი ცალკე შემოწმებას იმსახურებს.

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

ფაზა 1 და ფაზა 2 ცალკე განიხილეთ

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

სინტაქსი განხორციელებებს შორის არ გადადის. წყვილი, რომელიც OpenSwan-ში მუშაობს, მაგალითად phase2alg=aes_gcm ike=aes256-sha1;modp1024-თან ერთად, უნდა გადაითარგმნოს strongSwan-ის esp= და ike= ფორმაში, და ალგორითმების სახელები განსხვავდება. ვინაიდან GCM ავთენტიფიცირებას დაშიფვრის დროს ახდენს, მას ცალკე მთლიანობის ტრანსფორმაცია არ სჭირდება, SHA-სთან დაწყვილებული CBC ნაკრებისგან განსხვავებით. ერთი დემონიდან მეორეში თარგმანის გარეშე ჩასმული ფაზა 2-ის სტრიქონი წარმოქმნის უარყოფას, რომელიც სელექტორების შეუსაბამობად იკითხება.

შეამოწმეთ შვილობილი ასოციაცია და არა გვირაბის მაჩვენებელი

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

ipsec statusall

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

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

როცა სელექტორების დამთხვევის შემდეგაც ვერ მუშაობს

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

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

ჩაწერეთ სელექტორები, ფაზა 1-ისა და ფაზა 2-ის შეთავაზებები და წყაროს მისამართი ბილეთში. ეს ოთხი მნიშვნელობა ხსნის site-to-site-ის წარუმატებლობების უმეტესობას ზარის გარეშე.

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