Docker-ის პორტების გამოქვეყნება VPN-ის წინააღმდეგ: სად მიდის პასუხი

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

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

მიჰყევით tuple-ს დანიშნულების NAT-ის გავლით

ავიღოთ ჰოსტი 192.0.2.10-ზე, რომელიც TCP 2222-ს აქვეყნებს კონტეინერზე 172.30.240.5:22-ზე. მოთხოვნა 198.51.100.25-დან გარდაიქმნება კონტეინერამდე მისვლამდე და კონტეინერი პასუხობს როგორც თავად.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

რატომ უშვებს მას მხოლოდ ჰოსტის წესი

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

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

DNAT-ის შემდგომი შედარება სხვა hook-ია

Docker-ის firewall-ების დოკუმენტაცია აღნიშნავს, რომ ჩვეულებრივი მომხმარებლის ფილტრაცია ხედავს DNAT-ის შემდგომ დანიშნულებას, ამიტომ გამოქვეყნებული პორტის 2222-ის დამთხვევა ჩვეულებრივ წესში არ არის იგივე, რაც კონტეინერის პორტის 22-ის დამთხვევა. თუ საწყისი tuple მნიშვნელოვანია, გამოიყენეთ მხარდაჭერილი საწყისი დანიშნულების მექანიზმი იმის გამოცნობის ნაცვლად, თუ რომელი პორტი ჩანს.

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

დიზაინი A: გადაწყვეტილების გატანა კავშირის მდგომარეობად

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

  1. გამოყავით ნიშნის ველი და წესის პრიორიტეტი, რომლებიც არ ეჯახება Docker-ს, VPN-ს ან სხვა პოლიტიკის მფლობელს.
  2. იდენტიფიცირეთ მხოლოდ განზრახული ახალი WAN კავშირი DNAT-ამდე წერტილში, სადაც კავშირის თვალყურის დევნება ხელმისაწვდომია.
  3. ჩაწერეთ გადაწყვეტილება კავშირის ნიშანზე, თავად საწყისი მოთხოვნის WAN ცხრილში იძულების გარეშე.
  4. პასუხის მიმართულებით, მარშრუტიზაციამდე დაუბრუნეთ პაკეტს მხოლოდ თქვენივე ნიშნის ბიტები.
  5. აირჩიეთ სრული WAN ცხრილი საკმარისად ადრე, რომ VPN წესი ვერ მოიგოს პირველმა.

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

დიზაინი B: დასრულება ჰოსტზე

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

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

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

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

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

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