kubectl nevar atrisināt privātā klastera API caur OpenVPN

kubectl nespēj atrisināt vārdu, lai gan tunelis ir aktīvs un API privātā adrese joprojām atbild uz ping. Maršruts ir kārtībā; klients jautā risinātājam, kas nekad nav dzirdējis par klastera privāto zonu. Visbiežāk izmanto divus labojumus: nosūtīt virtuālā tīkla risinātāju katram VPN klientam vai piesaistīt vārdu lokāli ar hosts ierakstu vai nosacītu pāradresētāju. Tie atrisina vienus un tos pašus simptomus ar atšķirīgu atbildību, un to sajaukšana noved pie tā, ka komandas rediģē hosts failus katru reizi, kad galapunkts tiek pārbūvēts.

Atrisināšana un sasniedzamība nespēj darboties dažādos slāņos

Veiciet meklēšanu paši, pirms kaut ko maināt. getent hosts Linux vai nslookup Windows parāda, vai klients vispār saņem atbildi; taimauts vai NXDOMAIN norāda uz risinātāju, savukārt atbilde ar nepareizu adresi norāda uz novecojušu ierakstu vai publisku pāreju.

Pēc tam pārbaudiet, kuram serverim kubectl patiešām piesakās. kubeconfig konteksts glabā URL, un VPN maršruts to nepārraksta: ja konteksts nosauc publisku galapunktu, DNS var būt ideāls, un komanda tomēr neizdosies.

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

Trešais signāls ir kļūdas forma pēc meklēšanas. Vārds, kas atrisinās uz privāto adresi un pēc tam saņem TCP taimautu, ir ugunsmūra vai autorizētā tīkla problēma. Vārds, kas atrisinās uz publisku adresi, nozīmē, ka vaicājums izkļuva no privātās zonas. Turiet šos trīs iznākumus atsevišķi; katrs ved jūs pie cita atbildīgā.

A variants: nosūtīt virtuālā tīkla risinātāju tunelī

Kad VPN serveris darbojas virtuālā tīkla iekšienē, klienti var izmantot to pašu risinātāju kā servera hostdators. OpenVPN Community serveris nosūta DNS opciju; Access Server rāda to pašu iestatījumu administrēšanas saskarnē, un klientiem profils ir jālejupielādē no jauna, jo DNS direktīva ceļo tā iekšienē.

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

Maršruta rinda ir svarīga split-tunnel profilos. Risinātāja adreses nosūtīšana nav tas pats, kas tā padarīšana sasniedzamu: ja pa tuneli iet tikai klastera apakštīkls, vaicājums uz 10.0.0.4 iziet caur vietējo LAN un iet bojā. Nosūtiet resursdatora maršrutu risinātājam vai iekļaujiet tā apakštīklu tunelī.

Uzņemošajai pusei arī ir politika. Risinātājs, kas sasniedzams no klienta adrešu diapazona, joprojām var atteikt vaicājumus no tā, un privātā zona, kas saistīta ar virtuālo tīklu, atbild tikai klientiem, kas ierodas pa šī tīkla DNS ceļu. Ja meklēšana pēc nosūtīšanas beidzas ar taimautu, pārbaudiet risinātāja paša žurnālus, pirms atkal aiztikt klientu.

Klientā pārbaudiet, kas tika piemērots: resolvectl status systemd-resolved Linux, scutil --dns macOS, ipconfig /all Windows. Nosūtīts DNS serveris, kas nekad neparādās, nozīmē, ka profils netika pārlādēts.

B variants: hosts ieraksti un nosacīta pāradresācija

hosts ieraksts ir mazākais iespējamais labojums un trauslākais. Tas kartē vienu vārdu uz vienu adresi vienā mašīnā, tāpēc der demonstrācijai un salūzt, kad privātais galapunkts vai tā IP tiek pārbūvēts. Tas arī slēpj īsto plaisu no pārējās komandas.

Nosacīts pāradresētājs mērogojas labāk, nenosūtot DNS katram klientam. dnsmasq var nosūtīt vienu zonu VNet risinātājam un atstāt visu pārējo mierā: server=/cluster.internal/10.0.0.4. Windows DNS ir nosacīti pāradresētāji, un Windows klienti var izmantot NRPT kārtulu tādam pašam sadalījumam. Pāradresētājam joprojām vajadzīgs maršruts uz VNet risinātāju.

Pāradresācija saglabā parasto pārlūkošanu lokālu, kas ir svarīgi split tunnel gadījumā. Tā arī dod vienu vietu, kur reģistrēt privātās zonas vaicājumus, un vienu vietu, kas salūzt, kad pāradresētāja resursdators pārceļas.

Izvēlieties pēc atbildības, nevis pēc ērtības

Nosūtiet risinātāju, kad kontrolējat VPN profilu un vēlaties, lai strādātu katrs privātais vārds, ne tikai API. Izvēlieties pāradresētāju, kad klientiem jāsaglabā vietējais DNS visam pārējam, vai kad VPN pārvalda cita komanda nekā klasteri.

hosts ieraksti ir diagnostika, nevis izvietošana. Izmantojiet vienu, lai pierādītu, ka API ir sasniedzams, pēc tam noņemiet to un salabojiet risinātāja ceļu; atstājot to vietā, maršruta jautājums vēlāk pārvēršas dārgumu meklēšanā. Kādu vien variantu izvēlētos, pierakstiet zonu, risinātāja adresi un maršrutu, kas pārvadā vaicājumu.

Pārbaudiet API galapunktu, ne tikai vārdu

Kad meklēšana izdodas, iegūstiet API versijas galapunktu ar klastera CA. curl --cacert ca.crt https://api.internal.example:6443/version atdala TLS un autorizācijas kļūdas no DNS. 403 nozīmē, ka vārds un savienojums strādā, bet identitāte ne.

Pārbaudiet arī, vai klienta adrešu diapazonu atļauj klastera autorizētie tīkli vai ugunsmūris. Privāti klasteri bieži pieņem API satiksmi tikai no VNet vai peered diapazoniem, tāpēc tunelis, kas piešķir adreses no cita baseina, savienojas tīkla slānī un tiek izmests API līmenī.

Eskalējot pierakstiet četrus faktus: risinātāju, ko klients izmantoja, adresi, ko tas atgrieza, servera URL izvēlētajā kubeconfig kontekstā un pirmo neizdevušos darbību. Šis ieraksts pasaka nākamajam inženierim, vai mainīt DNS, maršrutēšanu vai ugunsmūra politiku, un tas aptur nākamo hosts faila rediģēšanu.

Sāciet ar meklēšanu, izvēlieties risinātāja ceļu, kas atbilst zonas īpašniekam, pēc tam pārbaudiet galapunktu. Ja visi trīs iztur, atlikusī problēma ir autorizācija, nevis vārdu atrisināšana.