DNAT VPN კონტეინერში: გადამისამართება, არა INPUT

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

თვალყური ადევნეთ პაკეტს თარგმნის შემდეგ

აიღეთ კლიენტების აუზი 10.90.0.0/24 და გვირაბის მისამართი 10.90.0.1. ერთ ხიდზე ორი კონტეინერია: 192.0.2.2 VPN-ს უშვებს, ხოლო 192.0.2.3 აპლიკაციას. კლიენტი უკავშირდება 10.90.0.1:8080-ს და VPN კონტეინერის სახელთა სივრცეში არსებული DNAT წესი მას აპლიკაციის რეალურ მისამართსა და პორტზე გადაწერს. შემდეგ მარშრუტი პაკეტს ხიდის გავლით აგზავნის. ეს მისამართები საილუსტრაციოა, არა განლაგების რეცეპტი.

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

ნებართვა გადამისამართების გზას ეკუთვნის

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

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

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker-ის ჯაჭვები თქვენი კონტეინერის ჯაჭვები არ არის

კონტეინერის სახელთა სივრცის შიგნით არსებული წესები Docker ჰოსტის წესები არ არის. როცა ტრაფიკი გვირაბის ინტერფეისიდან ხიდზე გადადის, ჰოსტის ხიდის firewall-მა შეიძლება სხვა გადაწყვეტილება მიიღოს. Docker-ის iptables backend-ის შემთხვევაში, დოკუმენტირებული გადამისამართების ჯაჭვები და DNAT-ის შემდგომი შესაბამისობის წერტილები სწორედ ის ადგილია, სადაც ეს გადაწყვეტილება ჩნდება.

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

დაბრუნების გზა შეგნებულ არჩევნად აქციეთ

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

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

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