kubectl OpenVPN üzərindən şəxsi klaster API-nin adını həll edə bilmir

Tunel işlək olsa da və API-nin şəxsi ünvanı ping-ə cavab versə də, kubectl ad axtarışında uğursuz olur. Marşrut qaydasındadır; müştəri klasterin şəxsi zonasını heç vaxt görməmiş həllediciyə müraciət edir. Ən çox iki düzəliş istifadə olunur: virtual şəbəkənin həlledicisini hər VPN müştərisinə göndərmək və ya adı hosts qeydi və ya şərti yönləndirici ilə yerli olaraq bərkitmək. Onlar eyni simptomu fərqli məsuliyyət ilə həll edir və onları qarışdırmaq komandaların hər dəfə son nöqtə yenidən qurulanda hosts fayllarını redaktə etməsi ilə nəticələnir.

Ad həlli və əlçatanlıq müxtəlif qatqılarda uğursuz olur

Heç nəyi dəyişməzdən əvvəl axtarışı özünüz aparın. Linux-da getent hosts və ya Windows-da nslookup müştərinin ümumiyyətlə cavab alıb-almadığını göstərir; fasilə və ya NXDOMAIN həllediciyə işarə edir, səhv ünvanlı cavab isə köhnəlmiş qeydə və ya ictimai keçidə işarə edir.

Sonra kubectl-in həqiqətən hansı serverə qoşulduğunu təsdiqləyin. kubeconfig konteksti URL saxlayır və VPN marşrutu onu yenidən yazmır: kontekst ictimai son nöqtəni göstərirsə, DNS mükəmməl ola bilər və əmr yenə də uğursuz olar.

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

Üçüncü siqnal axtarışdan sonrakı uğursuzluğun formasıdır. Şəxsi ünvana həll olunan adın ardınca TCP fasiləsi gəlirsə, bu firewall və ya icazəli şəbəkə problemidir. İctimai ünvana həll olunan ad sorğunun şəxsi zonadan çıxdığını bildirir. Bu üç nəticəni ayrı saxlayın; hər biri sizi başqa məsula yönəldir.

Variant A: virtual şəbəkə həlledicisini tunelə göndərin

VPN serveri virtual şəbəkənin içində işləyirsə, müştərilər server hostu ilə eyni həlledicidən istifadə edə bilər. OpenVPN Community-də server DNS seçimi göndərir; Access Server eyni parametri admin UI-də göstərir və müştərilər profili yenidən endirməlidir, çünki DNS direktivi onun içində gedir.

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

Marşrut sətri split-tunnel profillərində vacibdir. Həlledici ünvanını göndərmək onu əlçatan etməklə eyni şey deyil: tuneldən yalnız klaster subneti keçirsə, 10.0.0.4-ə sorğu yerli LAN ilə çıxır və ölür. Həlledici üçün host marşrutu göndərin və ya onun subnetini tunelə daxil edin.

Qəbul edən tərəfin də siyasəti var. Müştəri ünvan aralığından əlçatan həlledici yenə də ondan sorğuları rədd edə bilər və virtual şəbəkəyə bağlanmış şəxsi zona yalnız həmin şəbəkənin DNS yolu ilə gələn müştərilərə cavab verir. Göndərişdən sonra axtarış fasiləyə düşürsə, müştəriyə yenidən toxunmazdan əvvəl həlledicinin öz loglarına baxın.

Müştəridə nəyin tətbiq olunduğunu yoxlayın: systemd-resolved Linux-da resolvectl status, macOS-da scutil --dns, Windows-da ipconfig /all. Heç vaxt görünməyən göndərilmiş DNS serveri profilin yenidən yüklənmədiyini bildirir.

Variant B: hosts qeydləri və şərti yönləndirmə

hosts qeydi mümkün olan ən kiçik düzəliş və ən kövrək həlldir. O, bir adı bir maşında bir ünvana bağlayır, yəni demo üçün işləyir və şəxsi son nöqtə və ya onun IP-si yenidən qurulanda pozulur. O, həmçinin real boşluğu komandanın qalan hissəsindən gizlədir.

Şərti yönləndirici DNS-i hər müştəriyə göndərmədən daha yaxşı miqyaslanır. dnsmasq bir zonanı VNet həlledicisinə göndərə və qalan hər şeyi tək buraxa bilər: server=/cluster.internal/10.0.0.4. Windows DNS-də şərti yönləndiricilər var və Windows müştəriləri eyni bölmə üçün NRPT qaydasından istifadə edə bilər. Yönləndiriciyə yenə də VNet həlledicisinə marşrut lazımdır.

Yönləndirmə normal gəzintini yerli saxlayır, bu split tunnel-da vacibdir. O, həmçinin şəxsi zona üçün sorğuları qeyd etmək üçün bir yer və yönləndirici hostu köçəndə pozulacaq bir yer verir.

Rahatlığa görə deyil, məsuliyyətə görə seçin

VPN profilini idarə edirsinizsə və yalnız API deyil, hər şəxsi adın işləməsini istəyirsinizsə, həlledicini göndərin. Müştərilər qalan hər şey üçün yerli DNS-lərini saxlamalıdırsa və ya VPN klasterdən fərqli komanda tərəfindən idarə olunursa, yönləndirici seçin.

hosts qeydləri diaqnostikdir, yerləşdirmə deyil. API-nin əlçatan olduğunu sübut etmək üçün birini istifadə edin, sonra onu silin və həlledici yolunu düzəldin; onu yerində saxlamaq sonradan marşrut sualını xəzinə axtarışına çevirir. Hansı variantı seçsəniz də, zonanı, həlledici ünvanını və sorğunu daşıyan marşrutu yazın.

API son nöqtəsini sınayın, yalnız adı deyil

Axtarış uğurlu olduqdan sonra API-nin versiya son nöqtəsini klaster CA-sı ilə götürün. curl --cacert ca.crt https://api.internal.example:6443/version TLS və avtorizasiya uğursuzluqlarını DNS-dən ayırır. 403 adın və bağlantının işlədiyini, şəxsiyyətin isə işləmədiyini bildirir.

Müştəri ünvan aralığının klasterin icazəli şəbəkələri və ya firewall-u tərəfindən icazə verildiyini də yoxlayın. Şəxsi klasterlər çox vaxt API trafikini yalnız VNet və ya peered aralıqlardan qəbul edir, yəni fərqli hovuzdan ünvan verən tunel şəbəkə qatında qoşulur və API-də atılır.

Eskalasiya edərkən dörd faktı qeyd edin: müştərinin istifadə etdiyi həlledici, qaytardığı ünvan, seçilmiş kubeconfig kontekstindəki server URL-i və uğursuz olan ilk əməliyyat. Bu qeyd növbəti mühəndisə DNS, marşrut və ya firewall siyasətinin dəyişdirilməli olduğunu deyir və növbəti hosts faylı redaktəsinin qarşısını alır.

Axtarışla başlayın, zonanın kimə aid olduğuna uyğun həlledici yolunu seçin, sonra son nöqtəni yoxlayın. Üçü də keçərsə, qalan problem ad həlli deyil, avtorizasiyadır.