kubectl ვერ ხსნის კერძო კლასტერის API-ს OpenVPN-ის გავლით

kubectl სახელის ძიებისას ვარდება, თუმცა გვირაბი მუშაობს და API-ის კერძო მისამართი ჯერ კიდევ პასუხობს ping-ს. მარშრუტი რიგზეა; კლიენტი ეკითხება გამხსნელს, რომელსაც კლასტერის კერძო ზონაზე არასოდეს სმენია. ყველაზე ხშირად ორ შესწორებას იყენებენ: ვირტუალური ქსელის გამხსნელის ყველა VPN კლიენტისთვის გაგზავნას, ან სახელის ლოკალურად დამაგრებას hosts ჩანაწერით ან პირობითი გადამისამართებლით. ისინი ერთსა და იმავე სიმპტომს სხვადასხვა პასუხისმგებლობით ხსნიან, და მათი არევა იწვევს იმას, რომ გუნდები hosts ფაილებს ყოველ ჯერზე ასწორებენ, როცა საბოლოო წერტილი ხელახლა აშენდება.

გადაწყვეტა და ხელმისაწვდომობა სხვადასხვა დონეზე ვარდება

თვითონ შეასრულეთ ძიება, სანამ რამეს შეცვლით. getent hosts Linux-ზე ან nslookup Windows-ზე გეტყვით, იღებს კლიენტი საერთოდ პასუხს; დროის ამოწურვა ან NXDOMAIN გამხსნელზე მიუთითებს, ხოლო არასწორი მისამართის პასუხი მოძველებულ ჩანაწერზე ან საჯარო გავლაზე.

შემდეგ დაადასტურეთ, რომელ სერვერს უკავშირდება kubectl სინამდვილეში. kubeconfig კონტექსტი ინახავს URL-ს, და VPN მარშრუტი მას არ გადაწერს: თუ კონტექსტი საჯარო საბოლოო წერტილს ასახელებს, DNS შეიძლება სრულყოფილი იყოს და ბრძანება მაინც ვარდება.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

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

ვარიანტი A: ვირტუალური ქსელის გამხსნელი გვირაბში გაგზავნეთ

როცა VPN სერვერი ვირტუალური ქსელის შიგნით მუშაობს, კლიენტებს შეუძლიათ იმავე გამხსნელი გამოიყენონ, რომელსაც სერვერის ჰოსტი იყენებს. OpenVPN Community-ში სერვერი DNS პარამეტრს აგზავნის; Access Server იმავე პარამეტრს ადმინის ინტერფეისში აჩვენებს, და კლიენტებმა პროფილი ხელახლა უნდა ჩამოტვირთონ, რადგან DNS მითითება მის შიგნით მოძრაობს.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

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

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

კლიენტზე შეამოწმეთ, რა გამოიყენეს: resolvectl status systemd-resolved Linux-ზე, scutil --dns macOS-ზე, ipconfig /all Windows-ზე. გაგზავნილი DNS სერვერი, რომელიც არასოდეს ჩნდება, ნიშნავს, რომ პროფილი ხელახლა არ ჩაიტვირთა.

ვარიანტი B: hosts ჩანაწერები და პირობითი გადამისამართება

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

პირობითი გადამისამართებელი უკეთ სკალირდება DNS-ის ყველა კლიენტისთვის გაგზავნის გარეშე. dnsmasq-ს შეუძლია ერთი ზონა VNet-ის გამხსნელს გაუგზავნოს და დანარჩენი ყველაფერი მშვიდად დატოვოს: server=/cluster.internal/10.0.0.4. Windows DNS-ს აქვს პირობითი გადამისამართებლები, და Windows კლიენტებს შეუძლიათ NRPT წესი გამოიყენონ იმავე გაყოფისთვის. გადამისამართებელს მაინც სჭირდება მარშრუტი VNet-ის გამხსნელამდე.

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

აირჩიეთ პასუხისმგებლობის მიხედვით, არა მოხერხებულობის

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

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

შეამოწმეთ API-ის საბოლოო წერტილი, არა მხოლოდ სახელი

როცა ძიება წარმატებულია, აიღეთ API-ის ვერსიის საბოლოო წერტილი კლასტერის CA-თი. curl --cacert ca.crt https://api.internal.example:6443/version გამოყოფს TLS და ავტორიზაციის მარცხებს DNS-ისგან. 403 ნიშნავს, რომ სახელი და კავშირი მუშაობს, ხოლო იდენტობა არა.

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

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

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