kubectl nie potrafi rozwiązać API prywatnego klastra przez OpenVPN

kubectl zawodzi przy wyszukiwaniu nazwy, choć tunel działa, a prywatny adres API nadal odpowiada na ping. Trasa jest w porządku; klient pyta resolver, który nigdy nie słyszał o prywatnej strefie klastra. Najczęściej stosuje się dwie poprawki: wysłanie resolvera sieci wirtualnej do każdego klienta VPN albo przypięcie nazwy lokalnie wpisem hosts lub forwarderem warunkowym. Rozwiązują ten sam objaw z inną odpowiedzialnością, a mieszanie ich sprawia, że zespoły edytują pliki hosts za każdym razem, gdy punkt końcowy jest odbudowywany.

Rozwiązywanie i osiągalność zawodzą w różnych warstwach

Wykonaj zapytanie samodzielnie, zanim cokolwiek zmienisz. getent hosts w Linuksie lub nslookup w Windowsie mówi, czy klient w ogóle dostaje odpowiedź; przekroczenie limitu czasu lub NXDOMAIN wskazują resolver, a odpowiedź z błędnym adresem wskazuje nieaktualny rekord lub publiczny przepływ.

Następnie potwierdź, z którym serwerem kubectl faktycznie się łączy. Kontekst kubeconfig przechowuje URL, a trasa VPN go nie przepisuje: jeśli kontekst wskazuje publiczny punkt końcowy, DNS może być idealny, a polecenie nadal zawiedzie.

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

Trzecim sygnałem jest kształt awarii po zapytaniu. Nazwa rozwiązująca się na prywatny adres, po której następuje limit czasu TCP, to problem zapory lub sieci autoryzowanej. Nazwa rozwiązująca się na publiczny adres oznacza, że zapytanie wydostało się ze strefy prywatnej. Trzymaj te trzy wyniki osobno; każdy prowadzi do innego właściciela.

Opcja A: wysłać resolver sieci wirtualnej do tunelu

Gdy serwer VPN działa w sieci wirtualnej, klienci mogą używać tego samego resolvera co host serwera. W OpenVPN Community serwer wysyła opcję DNS; Access Server pokazuje to samo ustawienie w interfejsie administracyjnym, a klienci muszą ponownie pobrać profil, ponieważ dyrektywa DNS podróżuje w nim.

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

Linia trasy ma znaczenie w profilach split tunnel. Wysłanie adresu resolvera to nie to samo co uczynienie go osiągalnym: jeśli przez tunel przechodzi tylko podsieć klastra, zapytanie do 10.0.0.4 wychodzi przez lokalny LAN i ginie. Wyślij trasę hosta dla resolvera albo uwzględnij jego podsieć w tunelu.

Strona odbierająca też ma politykę. Resolver osiągalny z zakresu adresów klienta nadal może odrzucać jego zapytania, a strefa prywatna powiązana z siecią wirtualną odpowiada tylko klientom, którzy przychodzą przez ścieżkę DNS tej sieci. Jeśli zapytanie przekroczy limit czasu po wysłaniu, sprawdź logi samego resolvera, zanim ponownie dotkniesz klienta.

Na kliencie sprawdź, co zastosowano: resolvectl status w Linuksie z systemd-resolved, scutil --dns w macOS, ipconfig /all w Windowsie. Wysłany serwer DNS, który nigdy się nie pojawia, oznacza, że profil nie został ponownie wczytany.

Opcja B: wpisy hosts i przekazywanie warunkowe

Wpis hosts to najmniejsza możliwa poprawka i najbardziej krucha. Mapuje jedną nazwę na jeden adres na jednej maszynie, więc działa na pokazie i psuje się, gdy prywatny punkt końcowy lub jego IP jest odbudowywany. Ukrywa też prawdziwą lukę przed resztą zespołu.

Forwarder warunkowy skaluje się lepiej bez wysyłania DNS do każdego klienta. dnsmasq może wysłać jedną strefę do resolvera VNet, a wszystko inne zostawić w spokoju: server=/cluster.internal/10.0.0.4. DNS systemu Windows ma forwardery warunkowe, a klienci Windows mogą użyć reguły NRPT dla tego samego podziału. Forwarder nadal potrzebuje trasy do resolvera VNet.

Przekazywanie utrzymuje normalne przeglądanie lokalnie, co ma znaczenie w split tunelu. Daje też jedno miejsce do rejestrowania zapytań strefy prywatnej i jedno miejsce, które psuje się, gdy host forwardera się przenosi.

Wybieraj według odpowiedzialności, nie według wygody

Wyślij resolver, gdy kontrolujesz profil VPN i chcesz, aby działała każda prywatna nazwa, nie tylko API. Wybierz forwarder, gdy klienci muszą zachować lokalny DNS dla wszystkiego innego albo gdy VPN zarządza inny zespół niż klaster.

Wpisy hosts są diagnostyką, nie wdrożeniem. Użyj jednego, aby udowodnić, że API jest osiągalne, potem go usuń i napraw ścieżkę resolvera; pozostawienie go zamienia pytanie o routing w późniejszą wyprawę po skarb. Którąkolwiek opcję wybierzesz, zapisz strefę, adres resolvera i trasę, która przenosi zapytanie.

Testuj punkt końcowy API, nie tylko nazwę

Gdy zapytanie się powiedzie, pobierz punkt końcowy wersji API z CA klastra. curl --cacert ca.crt https://api.internal.example:6443/version oddziela awarie TLS i autoryzacji od DNS. 403 oznacza, że nazwa i połączenie działają, a tożsamość nie.

Sprawdź też, czy zakres adresów klienta jest dozwolony przez autoryzowane sieci lub zaporę klastra. Prywatne klastry często przyjmują ruch API tylko z VNet lub zakresów peered, więc tunel przydzielający adresy z innej puli łączy się w warstwie sieci i jest odrzucany na API.

Zapisz cztery fakty, gdy eskalujesz: resolver, którego użył klient, adres, który zwrócił, URL serwera w wybranym kontekście kubeconfig i pierwszą nieudaną operację. Ten zapis mówi następnemu inżynierowi, czy zmienić DNS, routing czy politykę zapory, i zatrzymuje kolejną edycję pliku hosts.

Zacznij od zapytania, wybierz ścieżkę resolvera odpowiadającą właścicielowi strefy, a potem zweryfikuj punkt końcowy. Jeśli wszystkie trzy przejdą, pozostałym problemem jest autoryzacja, nie rozwiązywanie nazw.