VPN კლიენტის IP Kubernetes-ში: შევინარჩუნოთ თუ SNAT გავუკეთოთ?
აირჩიეთ VPN კლიენტის რეალური მისამართის შენარჩუნებასა და Kubernetes-ში წყაროს NAT-ს შორის სამი პირობის მიხედვით, შემდეგ შეამოწმეთ დაბრუნების გზა და pod-ების ცვლა.
სადღაც გვირაბსა და backend-ს შორის კლიენტის მისამართი ან რჩება, ან იცვლება, და ორივე შედეგი დასაცავია. არჩევანი ეკუთვნის მიმღები სერვისის მფლობელს და არა მას, ვინც CNI დააყენა. როცა კლიენტის მიხედვით ავტორიზაციას, კვოტებს ან აუდიტის ჩანაწერებს მნიშვნელობა აქვს, მისამართმა ყოველი ნახტომი უნდა გადაიტანოს. როცა საერთო მიკუთვნება მისაღებია, წყაროს NAT აშორებს მარშრუტიზაციის პრობლემას, რომელსაც სხვაგვარად სამუდამოდ შეინარჩუნებდით.
სად იკარგება სინამდვილეში კლიენტის მისამართი
დისტანციური კლიენტის პაკეტი VPN pod-ში აღწევს შიდა წყაროთი გვირაბის დიაპაზონში, ვთქვათ 10.90.0.42. როცა pod გადაუგზავნის ამ პაკეტს ClusterIP-ის ან pod-ის IP-ისკენ, წყარო შეიძლება გადაწეროს სამმა სხვადასხვა მექანიზმმა. კვანძის CNI-ის masquerade წესი ფარავს ტრაფიკს, რომელსაც pod კლასტერის CIDR-ის გარეთ აგზავნის. სამიზნე კვანძზე kube-proxy-ის conntrack ჩანაწერი ფარავს თავად Service-ის ნახტომს. პროქსი, რომელიც კავშირს ამთავრებს, პაკეტს საერთოდ არ გადასცემს, ამიტომ წყარო, რომელსაც საბოლოოდ ხედავთ, პროქსის ეკუთვნის.
თითოეული მათგანი სხვადასხვა ფენაში ცხოვრობს, ამიტომ Service-ის ერთი ველი თითქმის არასდროს არ არემონტებს მთელ გზას.
VPN-ის საჯარო Service-ზე externalTrafficPolicy გადაწყვეტს მხოლოდ იმას, რა დაემართება გარე კავშირს: Local ინარჩუნებს დისტანციურ მისამართს იმ კვანძზე, რომელმაც ის მიიღო, ხოლო Cluster kube-proxy-ს აძლევს უფლებას პაკეტი სხვა კვანძს გადასცეს და იქ გააკეთოს masquerade. ეს პარამეტრი მართავს იმ listener-ს, რომელზეც თქვენი კლიენტები უკავშირდებიან. ის არაფერს ამბობს გაშიფრულ პაკეტზე, რომელსაც თქვენი VPN პროცესი შემდეგ კლასტერში მიმართავს.
სამი პირობა, რომლებიც კამათს წყვეტს
მე ვსვამ იმავე სამ კითხვას იმავე თანმიმდევრობით ყოველ ჯერზე, როცა ეს ჩნდება, რადგან პირველი ჩვეულებრივ ამთავრებს დისკუსიას. უპასუხეთ მათ კონკრეტული დატვირთვისთვის და არა მთელი კლასტერისთვის. ერთი კომპანიის შიგნით ორი კლასტერი შეიძლება სხვადასხვა პასუხამდე მივიდეს და ორივე მართალი იყოს.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
თუ backend პირველ კითხვაზე პასუხობს კი-თი, მეორეზე კი არა, თქვენ გაქვთ ქსელური სამუშაო და არა manifest, რომელიც უნდა შეასწოროთ. თუ მესამე სტრიქონი ამბობს პროქსის, მისამართი არასდროს გადარჩებოდა, და საპირისპიროს თქმა ერთი კვირის პაკეტების დაჭერა ღირს.
რას მოითხოვს preserve რეჟიმი ქსელისგან
წყაროს შენარჩუნება ნიშნავს, რომ სამიზნე კვანძმა ტრაფიკი 10.90.0.42-ზე უნდა დააბრუნოს აქტიური VPN კარიბჭის მეშვეობით. VPN-ის აუზი კლასტერის CIDR არ არის, ამიტომ არცერთი CNI მას თქვენ ნაცვლად არ მარშრუტიზებს ნაგულისხმევად. თქვენ თვითონ ამატებთ მარშრუტს და შემდეგ დარწმუნდებით, რომ კარიბჭის ის ბოლო წერტილი, რომელზეც ის მიუთითებს, გადაურჩება გადაგეგმვას.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2ის შემდეგი ნახტომი pod-ის მისამართია, ხოლო pod-ების მისამართები მოძრაობს. მიმართეთ მარშრუტი Service-ის VIP-ზე ან კვანძის მისამართზე, რომელიც ადგილზე რჩება, ან მიიღეთ, რომ ყოველი განდევნის შემდეგ კარიბჭეს დაედევნებით. უკუგზის ფილტრაცია მეორე ხაფანგია: მკაცრი რეჟიმი უგულებელყოფს პაკეტებს, რომელთა დაბრუნების გზა არ ემთხვევა ინტერფეისს, რომლითაც ისინი მოვიდნენ, და ეს ზუსტად შენარჩუნებული VPN ნაკადის ფორმაა.
სუსტი ვალიდაცია ხშირად განსხვავებაა მუშა დაბრუნების გზასა და იმ პასუხებს შორის, რომლებიც backend-ის დატოვების შემდეგ ქრება. VPN კვანძის masquerade წესებმა ასევე უნდა გამორიცხოს გვირაბის დიაპაზონი, თორემ გადაგზავნილი პაკეტი გადის pod-ის მისამართით, მიუხედავად იმისა, რა მარშრუტი ააგეთ. ამ გამორიცხვის გამოხატვას სჯობს თავად CNI-ის კონფიგურაციაში, ვიდრე iptables-ის ხელით რედაქტირება, რადგან აგენტი გადატვირთვისას გადაწერს თავის ჯაჭვებს და თქვენი ხელით დაწერილი წესი ზუსტად შემდეგ განახლებამდე ძლებს.
NetworkPolicy წვდომის კონტროლია და არა მარშრუტიზაცია. პოლიტიკის გამკაცრება არასდროს აღადგენს მისამართს, რომელიც masquerade-მა უკვე შეცვალა.
რა ღირს SNAT და როგორ ჩავწეროთ ის
კლასტერისკენ წყაროს NAT უფრო იაფი დიზაინია და ეს შეცდომა არ არის. Backend ხედავს VPN pod-ის ან კვანძის მისამართს, ჩანაწერები ერთმანეთს ემთხვევა და დაბრუნების მარშრუტი საერთოდ არ უნდა არსებობდეს. რასაც კარგავთ, არის ორი კლიენტის გარჩევის უნარი ქსელურ დონეზე, ამიტომ კვოტები, აკრძალვები და აუდიტის კვალი სხვა ადგილიდან უნდა მოვიდეს.
ჩვეულებრივ ეს სხვა ადგილი აპლიკაციაა: სესიის ტოკენი, ხელმოწერილი header ან PROXY პროტოკოლის სტრიქონი, რომელსაც თქვენს მიერ კონტროლირებული პროქსი წერს. ისინი მიმღებს აძლევენ იდენტობას, რომლის ენდობაც მხოლოდ მაშინ შეუძლია, როცა პროქსი გზაზეა და header-ის დაყენება კლიენტის მხრიდან შეუძლებელია. იყავით ცხადი runbook-ში, რომელი მოქმედებს, რადგან შემდეგი ინჟინერი ჩათვლის, რომ ჩანაწერში მოცემული მისამართი კლიენტია. ასე არ არის და ერთი ინციდენტი საკმარისია, რომ ეს დაშვება ძვირი გახდეს.
გაცვლა პატიოსანი რჩება მანამ, სანამ ის ჩაწერილია.
შემოწმებები, რომლებიც მუშა გზას იღბლიანისგან გამოყოფს
სცადეთ ახალი კავშირით და არა ქეშირებულით, და სცადეთ ორივე მიმართულებით. რამდენიმე ხარვეზი წყვეტილად მხოლოდ იმიტომ გამოიყურება, რომ ახალი ნაკადები გადაწერილ გზას მიჰყვება.
დაიჭირეთ tuple სამ წერტილში ერთი უფლებამოსილი მოთხოვნის დროს: გაშიფვრისთანავე, VPN pod-ის გამოსვლის ინტერფეისზე და backend-ზე. თუ წყარო იცვლება მეორე და მესამე დაჭერას შორის, მიზეზი pod-ის ქვემოთა ნაწილშია. თუ იცვლება მეორემდე, თავად pod თარგმნის.
შემდეგ წაშალეთ VPN pod და გაიმეორეთ ტესტი, სანამ ის ხელახლა იგეგმება. შენარჩუნებული გზა, რომელიც განდევნისას იმტვრევა, დაუმთავრებელია, და ასევე NAT წესი, რომელიც მიბმულია მისამართზე, რომელიც აღარ არსებობს. ბოლოს, გაგზავნეთ ერთი მოთხოვნა წყაროდან, რომლისთვისაც უარი მოგელოდებათ და დაადასტურეთ, რომ უარი პოლიტიკიდან მოდის და არა დაკარგული მარშრუტიდან.