Docker-ის პორტების გამოქვეყნება და VPN წყაროები: ორი დამთხვევა, რომლებსაც გამოტოვებთ

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

მითი: დაუშვით VPN სერვერი და დამთავრდა

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

ამიტომ ფრაზა VPN სერვერის IP აღწერს ვარაუდს და არა დაკვირვებას. სანამ არ იცით, ორი კონსტრუქციიდან რომელია თქვენს წინ, წესი ვარაუდია.

წყარო: კლიენტების აუზი თუ თარგმნილი შესახვევი

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

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

პორტი: DNAT ცვლის რიცხვს, რომელსაც ადარებთ

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

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

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

ჯაჭვი: DOCKER-USER, და არა INPUT

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

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

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

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

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