A kubectl nem tudja feloldani a privát klaszter API-ját OpenVPN-en keresztül

A kubectl névfeloldáskor hibázik, miközben az alagút él, és az API privát címe még válaszol a pingre. Az útvonal rendben van; a kliens olyan feloldót kérdez, amely soha nem hallott a klaszter privát zónájáról. Két javítás a leggyakoribb: a virtuális hálózat feloldójának kiküldése minden VPN-kliensnek, vagy a név helyi rögzítése hosts-bejegyzéssel vagy feltételes továbbítóval. Ugyanazt a tünetet oldják meg eltérő felelősséggel, és összekeverésük miatt szerkesztik a csapatok a hosts-fájlokat minden alkalommal, amikor egy végpont újraépül.

A feloldás és az elérhetőség különböző rétegekben hibázik

Futtassa le a lekérdezést saját maga, mielőtt bármit módosítana. getent hosts Linuxon vagy nslookup Windowson megmondja, kap-e egyáltalán választ a kliens; az időtúllépés vagy az NXDOMAIN a feloldóra mutat, míg a rossz című válasz egy elavult rekordra vagy nyilvános átjárásra.

Ezután erősítse meg, melyik kiszolgálót hívja valójában a kubectl. A kubeconfig-környezet URL-t tárol, és a VPN-útvonal nem írja át: ha a környezet nyilvános végpontot nevez meg, a DNS tökéletes lehet, és a parancs mégis elbukik.

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

A harmadik jel a hiba alakja a lekérdezés után. Ha egy név a privát címre oldódik, majd TCP-időtúllépés következik, az tűzfal- vagy engedélyezett hálózati probléma. Ha egy név nyilvános címre oldódik, az azt jelenti, hogy a lekérdezés kiszökött a privát zónából. Tartsa külön ezt a három kimenetet; mindegyik más felelőshöz küldi.

A lehetőség: a virtuális hálózat feloldójának kiküldése az alagútba

Amikor a VPN-kiszolgáló a virtuális hálózaton belül fut, a kliensek ugyanazt a feloldót használhatják, mint a kiszolgáló gazdagépe. Az OpenVPN Communityben a kiszolgáló DNS-beállítást küld ki; az Access Server ugyanezt a beállítást mutatja a felügyeleti felületen, és a klienseknek újra le kell tölteniük a profilt, mert a DNS-utasítás abban utazik.

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

Az útvonal-sor a split-tunnel profilokon számít. Egy feloldócím kiküldése nem ugyanaz, mint elérhetővé tenni: ha csak a klaszter alhálózata megy át az alagúton, a 10.0.0.4-re menő lekérdezés a helyi LAN-on keresztül távozik és elhal. Küldjön gazdagép-útvonalat a feloldónak, vagy vegye fel annak alhálózatát az alagútba.

A fogadó oldalnak is van szabályzata. Egy a kliens címtartományából elérhető feloldó még mindig visszautasíthatja az onnan jövő lekérdezéseket, és a virtuális hálózathoz kapcsolt privát zóna csak azon klienseknek válaszol, amelyek az adott hálózat DNS-útvonalán érkeznek. Ha a lekérdezés a kiküldés után időtúllépésbe fut, nézze meg a feloldó saját naplóit, mielőtt újra hozzányúl a klienshez.

A kliensen ellenőrizze, mi lett alkalmazva: resolvectl status systemd-resolved Linuxon, scutil --dns macOS-en, ipconfig /all Windowson. Egy kiküldött DNS-kiszolgáló, amely soha nem jelenik meg, azt jelenti, hogy a profil nem töltődött be újra.

B lehetőség: hosts-bejegyzések és feltételes továbbítás

A hosts-bejegyzés a legkisebb lehetséges javítás és a legtörékenyebb. Egy nevet egy címhez rendel egy gépen, tehát demóhoz működik, és elromlik, amikor a privát végpont vagy annak IP-je újraépül. Elrejti a valódi hiányt a csapat többi tagja elől is.

A feltételes továbbító jobban skálázódik anélkül, hogy DNS-t küldene minden kliensnek. A dnsmasq egy zónát a VNet feloldójához küldhet, és minden mást békén hagyhat: server=/cluster.internal/10.0.0.4. A Windows DNS-nek vannak feltételes továbbítói, és a Windows-kliensek NRPT-szabályt használhatnak ugyanerre a felosztásra. A továbbítónak továbbra is kell útvonal a VNet feloldójához.

A továbbítás helyben tartja a normál böngészést, ami split tunnelen számít. Egyetlen helyet ad a privát zóna lekérdezéseinek naplózására, és egyetlen helyet, amely elromlik, amikor a továbbító gazdagépe elköltözik.

Tulajdonjog szerint válasszon, ne kényelem szerint

Küldje ki a feloldót, ha Ön irányítja a VPN-profilt, és azt szeretné, hogy minden privát név működjön, ne csak az API. Válasszon továbbítót, ha a klienseknek meg kell tartaniuk a helyi DNS-t minden másra, vagy ha a VPN-t a klasztertől eltérő csapat kezeli.

A hosts-bejegyzések diagnosztika, nem telepítés. Használjon egyet annak bizonyítására, hogy az API elérhető, majd távolítsa el, és javítsa a feloldó útvonalát; ha a helyén marad, az útvonalkérdés később kincsvadászattá válik. Bármelyik lehetőséget választja, írja le a zónát, a feloldó címét és az útvonalat, amely a lekérdezést viszi.

Az API-végpontot tesztelje, ne csak a nevet

Amikor a lekérdezés sikerül, kérje le az API verzióvégpontját a klaszter CA-jával. A curl --cacert ca.crt https://api.internal.example:6443/version elválasztja a TLS- és engedélyezési hibákat a DNS-től. A 403 azt jelenti, hogy a név és a kapcsolat működik, az identitás nem.

Azt is ellenőrizze, hogy a kliens címtartományát engedélyezik-e a klaszter engedélyezett hálózatai vagy tűzfala. A privát klaszterek gyakran csak a VNet vagy peered tartományok felől fogadnak API-forgalmat, így egy másik készletből címeket osztó alagút a hálózati rétegen kapcsolódik, és az API-nál eldobódik.

Négy tényt rögzítsen, amikor eszkalál: a kliens által használt feloldót, a visszaadott címet, a kiválasztott kubeconfig-környezet kiszolgáló URL-jét és az első sikertelen műveletet. Ez a feljegyzés megmondja a következő mérnöknek, hogy DNS-t, útvonalválasztást vagy tűzfalszabályt kell-e módosítani, és megállítja a következő hosts-fájl-szerkesztést.

Kezdje a lekérdezéssel, válassza a zóna tulajdonosához illő feloldóútvonalat, majd ellenőrizze a végpontot. Ha mindhárom átmegy, a fennmaradó probléma az engedélyezés, nem a névfeloldás.