kubectl ei voi ratkaista yksityisen klusterin API:a OpenVPN:n yli

kubectl epäonnistuu nimihaussa, vaikka tunneli on pystyssä ja API:n yksityinen osoite vastaa edelleen pingiin. Reitti on kunnossa; asiakas kysyy resolverilta, joka ei ole koskaan kuullut klusterin yksityisestä vyöhykkeestä. Kaksi korjausta on yleisimpiä: työnnetään virtuaaliverkon resolveri jokaiselle VPN-asiakkaalle tai kiinnitetään nimi paikallisesti hosts-tietueella tai ehdollisella välittäjällä. Ne ratkaisevat saman oireen eri omistajuudella, ja niiden sekoittaminen johtaa siihen, että tiimit muokkaavat hosts-tiedostoja joka kerta, kun päätepiste rakennetaan uudelleen.

Nimenseivitys ja tavoitettavuus epäonnistuvat eri kerroksissa

Tee haku itse ennen kuin muutat mitään. getent hosts Linuxissa tai nslookup Windowsissa kertoo, saako asiakas vastausta lainkaan; aikakatkaisu tai NXDOMAIN viittaa resolveriin, kun taas väärällä osoitteella tuleva vastaus viittaa vanhentuneeseen tietueeseen tai julkiseen läpikulkuun.

Vahvista sitten mihin palvelimeen kubectl todella yhdistää. kubeconfig-konteksti tallentaa URL:n, eikä VPN-reitti kirjoita sitä uudelleen: jos konteksti nimeää julkisen päätepisteen, DNS voi olla täydellinen ja komento epäonnistuu silti.

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

Kolmas signaali on vian muoto haun jälkeen. Nimi, joka ratkeaa yksityiseen osoitteeseen ja jota seuraa TCP-aikakatkaisu, on palomuurin tai valtuutetun verkon ongelma. Nimi, joka ratkeaa julkiseen osoitteeseen, tarkoittaa, että kysely pääsi yksityiseltä vyöhykkeeltä ulos. Pidä nämä kolme tulosta erillään; kukin vie sinut eri omistajalle.

Vaihtoehto A: työnnä virtuaaliverkon resolveri tunneliin

Kun VPN-palvelin toimii virtuaaliverkon sisällä, asiakkaat voivat käyttää samaa resolveria kuin palvelimen isäntä. OpenVPN Communityssa palvelin työntää DNS-asetuksen; Access Server näyttää saman asetuksen hallintakäyttöliittymässä, ja asiakkaiden on ladattava profiili uudelleen, koska DNS-direktiivi kulkee sen sisällä.

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

Reittirivillä on merkitystä split tunnel -profiileissa. Resolverin osoitteen työntäminen ei ole sama kuin sen tekeminen tavoitettavaksi: jos vain klusterin aliverkko kulkee tunnelin kautta, kysely osoitteeseen 10.0.0.4 lähtee paikallisen LANin kautta ja kuolee. Työnnä resolverille isäntäreitti tai sisällytä sen aliverkko tunneliin.

Vastaanottavalla puolella on myös käytäntö. Asiakkaan osoitealueelta tavoitettavissa oleva resolveri voi silti hylätä sieltä tulevat kyselyt, ja virtuaaliverkkoon liitetty yksityinen vyöhyke vastaa vain asiakkaille, jotka saapuvat kyseisen verkon DNS-polkua pitkin. Jos haku aikakatkeaa työnnön jälkeen, tarkista resolverin omat lokit ennen kuin kosket asiakkaaseen uudelleen.

Tarkista asiakkaalta, mitä otettiin käyttöön: resolvectl status systemd-resolved Linuxissa, scutil --dns macOS:ssa, ipconfig /all Windowsissa. Työnnetty DNS-palvelin, joka ei koskaan ilmesty, tarkoittaa, ettei profiilia ladattu uudelleen.

Vaihtoehto B: hosts-tietueet ja ehdollinen välitys

hosts-tietue on pienin mahdollinen korjaus ja haurain. Se yhdistää yhden nimen yhteen osoitteeseen yhdellä koneella, joten se toimii demossa ja hajoaa, kun yksityinen päätepiste tai sen IP rakennetaan uudelleen. Se myös piilottaa todellisen aukon muulta tiimiltä.

Ehdollinen välittäjä skaalautuu paremmin työntämättä DNS:ää jokaiselle asiakkaalle. dnsmasq voi lähettää yhden vyöhykkeen VNet-resolverille ja jättää kaiken muun rauhaan: server=/cluster.internal/10.0.0.4. Windows DNS:ssä on ehdolliset välittäjät, ja Windows-asiakkaat voivat käyttää NRPT-sääntöä samaan jakoon. Välittäjä tarvitsee silti reitin VNet-resolverille.

Välitys pitää normaalin selailun paikallisena, millä on merkitystä split tunnelissa. Se antaa myös yhden paikan kirjata yksityisen vyöhykkeen kyselyitä ja yhden paikan, joka hajoaa, kun välittäjän isäntä siirtyy.

Valitse omistajuuden, älä mukavuuden mukaan

Työnnä resolveri, kun hallitset VPN-profiilia ja haluat jokaisen yksityisen nimen toimivan, et vain API:n. Valitse välittäjä, kun asiakkaiden on pidettävä paikallinen DNS kaikelle muulle, tai kun VPN:tä hallitsee eri tiimi kuin klusteria.

hosts-tietueet ovat diagnostiikkaa, eivät käyttöönotto. Käytä yhtä todistamaan, että API on tavoitettavissa, poista se sitten ja korjaa resolverin polku; paikalleen jättäminen muuttaa reitityskysymyksen myöhemmin aarteenetsinnäksi. Minkä vaihtoehdon valitsetkin, kirjoita ylös vyöhyke, resolverin osoite ja reitti, joka kuljettaa kyselyn.

Testaa API-päätepistettä, älä vain nimeä

Kun haku onnistuu, hae API:n versiopäätepiste klusterin CA:lla. curl --cacert ca.crt https://api.internal.example:6443/version erottaa TLS- ja valtuutusvirheet DNS:stä. 403 tarkoittaa, että nimi ja yhteys toimivat ja identiteetti ei.

Tarkista myös, sallivatko klusterin valtuutetut verkot tai palomuuri asiakkaan osoitealueen. Yksityiset klusterit hyväksyvät API-liikennettä usein vain VNetistä tai peering-alueilta, joten eri poolista osoitteita jakava tunneli yhdistää verkkokerroksella ja pudotetaan API:ssa.

Kirjaa neljä tosiasiaa, kun eskaloit: resolveri, jota asiakas käytti, osoite, jonka se palautti, palvelimen URL valitussa kubeconfig-kontekstissa ja ensimmäinen epäonnistunut toiminto. Tämä kirjaus kertoo seuraavalle insinöörille, muutetaanko DNS:ää, reititystä vai palomuurikäytäntöä, ja se pysäyttää seuraavan hosts-tiedoston muokkauksen.

Aloita hausta, valitse resolverin polku, joka vastaa vyöhykkeen omistajaa, ja vahvista sitten päätepiste. Jos kaikki kolme menevät läpi, jäljellä oleva ongelma on valtuutus, ei nimenseivitys.