kubectl kin de API fan it privee cluster net oplosse oer OpenVPN

kubectl mislearret by namsocht wylst de tunnel oan stiet en it privee adres fan de API noch op in ping antwurdet. De rûte is goed; de klant freget in oplosser dy't nea fan de privee sône fan it cluster heard hat. Twa ferbetterings wurde it meast brûkt: de oplosser fan it firtuele netwurk nei elke VPN-klant stjoere, of de namme lokaal fêstsette mei in hosts-yngong of in betingst trochstjoerder. Se lossen itselde symptoom op mei oare ferantwurdlikens, en it trochinoar heljen is hoe't teams hosts-bestannen bewurkje elke kear as in einpunt wer opboud wurdt.

Oplossing en berikberens mislearje op ferskate lagen

Doch it sykjen sels foardat jo wat feroarje. getent hosts op Linux of nslookup op Windows fertelt jo oft de klant hielendal in antwurd krijt; in time-out of NXDOMAIN wiist nei de oplosser, wylst in antwurd mei it ferkearde adres nei in ferâldere record of in iepenbiere trochgong wiist.

Befêstigje dan hokker tsjinner kubectl eins oansprekt. In kubeconfig-kontekst bewarret in URL, en in VPN-rûte skriuwt dy net oer: as de kontekst in iepenbier einpunt neamt, kin DNS perfekt wêze en it kommando dochs mislearje.

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

It tredde sinjaal is de foarm fan de mislearring nei it sykjen. In namme dy't nei it privee adres oplost en dan in TCP-time-out krijt, is in probleem fan 'e firewall of fan in autorisearre netwurk. In namme dy't nei in iepenbier adres oplost, betsjut dat de fraach de privee sône ûntsnapt is. Hâld dy trije útkomsten apart; elk stjoert jo nei in oare eigner.

Opsje A: stjoer de oplosser fan it firtuele netwurk de tunnel yn

As de VPN-tsjinner binnen it firtuele netwurk draait, kinne klanten deselde oplosser brûke as de tsjinnerhost. Yn OpenVPN Community stjoert de tsjinner in DNS-opsje; Access Server lit deselde ynstelling sjen yn 'e admin-UI, en klanten moatte it profyl op 'e nij downloade om't de DNS-direktive deryn reizget.

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

De rûteline is wichtich by split-tunnel-profylen. It stjoeren fan in oplosseradres is net itselde as it berikber meitsjen: as allinnich it subnet fan it cluster troch de tunnel giet, ferlit de fraach nei 10.0.0.4 it lokale LAN en stjert. Stjoer in hostrûte foar de oplosser, of nim syn subnet op yn 'e tunnel.

De ûntfangende kant hat ek in belied. In oplosser dy't berikber is fan it adresberik fan 'e klant kin fragen dêrwei dochs wegerje, en in privee sône dy't oan it firtuele netwurk keppele is, antwurdet allinnich klanten dy't fia it DNS-paad fan dat netwurk komme. As it sykjen nei it stjoeren útrint, besjoch dan de eigen logs fan 'e oplosser foardat jo de klant wer oanreitsje.

Op 'e klant, kontrolearje wat tapast is: resolvectl status op systemd-resolved Linux, scutil --dns op macOS, ipconfig /all op Windows. In stjoerde DNS-tsjinner dy't nea ferskynt, betsjut dat it profyl net op 'e nij laden is.

Opsje B: hosts-yngongen en betingst trochstjoeren

In hosts-yngong is de lytste mooglike ferbettering en de meast brekbere. Hy keppelt ien namme oan ien adres op ien masjine, dus it wurket foar in demo en brekt as it privee einpunt of syn IP wer opboud wurdt. It ferberget ek it echte gat foar de rest fan it team.

In betingst trochstjoerder skalet better sûnder DNS nei elke klant te stjoeren. dnsmasq kin ien sône nei de VNet-oplosser stjoere en al it oare gewurde litte: server=/cluster.internal/10.0.0.4. Windows DNS hat betingste trochstjoerders, en Windows-klanten kinne in NRPT-regel brûke foar deselde splitsing. De trochstjoerder hat noch hieltyd in rûte nei de VNet-oplosser nedich.

Trochstjoeren hâldt normaal browsen lokaal, wat fan belang is by split tunnel. It jout jo ek ien plak om fragen foar de privee sône te loggen, en ien plak dat brekt as de trochstjoerderhost ferhuze.

Kies nei eigendom, net nei gemak

Stjoer de oplosser as jo it VPN-profyl beheare en wolle dat elke privee namme wurket, net allinnich de API. Kies in trochstjoerder as klanten har lokale DNS foar al it oare hâlde moatte, of as it VPN troch in oar team as it cluster beheard wurdt.

hosts-yngongen binne in diagnostyk, net in ynset. Brûk ien om te bewizen dat de API berikber is, ferwiderje it dan en reparearje it paad fan 'e oplosser; it litten stean makket fan in rûtefraach letter in skatkwerij. Hokker opsje jo ek kieze, skriuw de sône, it oplosseradres en de rûte dy't de fraach draacht op.

Test it API-einpunt, net allinnich de namme

Sadree't it sykjen slagget, helje it ferzje-einpunt fan de API op mei de cluster-CA. curl --cacert ca.crt https://api.internal.example:6443/version skiedt TLS- en autorisaasjeflaters fan DNS. In 403 betsjut dat de namme en ferbining wurkje en de identiteit net.

Kontrolearje ek oft it adresberik fan 'e klant tastien is troch de autorisearre netwurken of firewall fan it cluster. Privee clusters akseptearje API-ferkear faak allinnich fan it VNet of fan peared berikken, dus in tunnel dy't adressen út in oare pool tawiist, ferbynt op 'e netwurklaach en wurdt by de API weilitten.

Skriuw fjouwer feiten op as jo eskalearje: de oplosser dy't de klant brûkte, it adres dat er weromjoech, de tsjinner-URL yn 'e keazen kubeconfig-kontekst, en de earste operaasje dy't mislearre. Dat ferslach fertelt de folgjende yngenieur oft DNS, rûte of firewallbelied feroare wurde moat, en it stopet de folgjende hosts-bestânbewurking.

Begjin mei it sykjen, kies it paad fan 'e oplosser dat past by wa't de sône hat, en kontrolearje dan it einpunt. As alle trije slagje, is it oerbleaune probleem autorisaasje, net namme-oplossing.