ჰოსტი აღწევს IPsec პარტნიორს, Docker კონტეინერი — არა

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

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

დაიწყეთ ერთი სამიზნით და ორი წყაროთი

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

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

წაიკითხეთ პოლიტიკები სანამ Docker-ს შეეხებით

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

ip rule show
ip route show table all
ip xfrm policy

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

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

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

Docker-ის Linux ხიდის ფაირვოლი შეიძლება დაბლოკოს გადამისამართება IPsec-ისგან დამოუკიდებლად. iptables backend-ით შეამოწმეთ FORWARD გზა და DOCKER-USER გადაწყვეტილებები, გახსოვდეთ, რომ ადრინდელი განაჩენის შემდეგ დამატებული წესი შეიძლება არასოდეს შესრულდეს. nftables backend სხვაგვარად ინტეგრირდება, ამიტომ ნუ შექმნით DOCKER-USER ჯაჭვს მხოლოდ იმიტომ, რომ iptables-ის მაგალითმა ასე უწოდა; შეამოწმეთ, რომელ backend-ს იყენებს თქვენი daemon სინამდვილეში.

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

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

შემდეგ გადაწყვიტეთ მარშრუტიზებული თუ თარგმნილი

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

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

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

გადაამოწმეთ ახალი კავშირით და არა გადატვირთვით

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

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