kubectl haiwezi kutatua API ya kundi la kibinafsi kupitia OpenVPN

kubectl inashindwa katika utafutaji wa jina wakati tuneli iko hewani na anwani ya kibinafsi ya API bado inajibu ping. Njia ni sawa; mteja anauliza kitatuzi ambacho hakijawahi kusikia kuhusu eneo la kibinafsi la kundi. Marekebisho mawili yanatumika zaidi: kutuma kitatuzi cha mtandao pepe kwa kila mteja wa VPN, au kufunga jina kienyeji kwa ingizo la hosts au kipitishaji cha masharti. Yanatatua dalili hiyo hiyo kwa umiliki tofauti, na kuyachanganya ndiko kunakofanya timu kuishia kuhariri faili za hosts kila kituo kinapojengwa upya.

Utatuzi na ufikikaji hushindwa katika tabaka tofauti

Fanya utafutaji mwenyewe kabla ya kubadilisha chochote. getent hosts kwenye Linux au nslookup kwenye Windows inakuambia kama mteja anapata jibu kabisa; muda kuisha au NXDOMAIN huelekeza kwenye kitatuzi, wakati jibu lenye anwani isiyo sahihi huelekeza kwenye rekodi ya zamani au mwanya wa umma.

Kisha thibitisha ni seva gani kubectl inaunganisha kweli. Muktadha wa kubeconfig huhifadhi URL, na njia ya VPN haiiandiki upya: kama muktadha unataja kituo cha umma, DNS inaweza kuwa kamili na amri bado ishindwe.

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

Ishara ya tatu ni umbo la kushindwa baada ya utafutaji. Jina linalotatuliwa hadi anwani ya kibinafsi kisha kukumbana na muda kuisha wa TCP ni tatizo la firewall au mtandao ulioidhinishwa. Jina linalotatuliwa hadi anwani ya umma linamaanisha kuwa ombi lilitoka nje ya eneo la kibinafsi. Tenganisha matokeo hayo matatu; kila moja linakupeleka kwa mmiliki tofauti.

Chaguo A: tuma kitatuzi cha mtandao pepe ndani ya tuneli

Wakati seva ya VPN inafanya kazi ndani ya mtandao pepe, wateja wanaweza kutumia kitatuzi kile kile cha mwenyeji wa seva. Katika OpenVPN Community seva hutuma chaguo la DNS; Access Server huonyesha mpangilio huo huo kwenye kiolesura cha usimamizi, na wateja lazima wapakue wasifu tena kwa sababu maagizo ya DNS husafiri ndani yake.

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

Mstari wa njia ni muhimu katika wasifu wa split tunnel. Kutuma anwani ya kitatuzi si sawa na kuifanya ifikike: kama ni subnet ya kundi pekee inayopita kwenye tuneli, ombi kwa 10.0.0.4 hutoka kupitia LAN ya ndani na kufa. Tuma njia ya mwenyeji kwa kitatuzi, au jumuisha subnet yake kwenye tuneli.

Upande unaopokea pia una sera. Kitatuzi kinachofikika kutoka safu ya anwani za mteja kinaweza kukataa maombi kutoka humo, na eneo la kibinafsi lililounganishwa na mtandao pepe hujibu wateja wanaofika kupitia njia ya DNS ya mtandao huo pekee. Kama utafutaji unaisha kwa muda baada ya kutuma, angalia kumbukumbu za kitatuzi yenyewe kabla ya kugusa mteja tena.

Kwenye mteja, thibitisha kile kilichotumika: resolvectl status kwenye Linux ya systemd-resolved, scutil --dns kwenye macOS, ipconfig /all kwenye Windows. Seva ya DNS iliyotumwa ambayo haionekani kamwe inamaanisha wasifu haukupakiwa upya.

Chaguo B: maingizo ya hosts na upitishaji wa masharti

Ingizo la hosts ni marekebisho madogo zaidi yanayowezekana na dhaifu zaidi. Hulinganisha jina moja na anwani moja kwenye mashine moja, kwa hivyo hufanya kazi kwa onyesho na huvunjika kituo cha kibinafsi au IP yake inapojengwa upya. Pia huficha pengo halisi kutoka kwa timu nyingine.

Kipitishaji cha masharti hukua vizuri zaidi bila kutuma DNS kwa kila mteja. dnsmasq inaweza kutuma eneo moja kwa kitatuzi cha VNet na kuacha mengine yote: server=/cluster.internal/10.0.0.4. DNS ya Windows ina vipitishaji vya masharti, na wateja wa Windows wanaweza kutumia kanuni ya NRPT kwa mgawanyo huo huo. Kipitishaji bado kinahitaji njia kwa kitatuzi cha VNet.

Upitishaji huweka kuvinjari kawaida kienyeji, jambo ambalo ni muhimu kwenye split tunnel. Pia linakupa mahali pamoja pa kurekodi maombi ya eneo la kibinafsi, na mahali pamoja panapovunjika mwenyeji wa kipitishaji anapohama.

Chagua kwa umiliki, si kwa urahisi

Tuma kitatuzi unapodhibiti wasifu wa VPN na unataka kila jina la kibinafsi lifanye kazi, si API pekee. Chagua kipitishaji wakati wateja wanapaswa kuweka DNS yao ya ndani kwa mambo mengine yote, au wakati VPN inasimamiwa na timu tofauti na kundi.

Maingizo ya hosts ni uchunguzi, si uwekaji. Tumia moja kuthibitisha kuwa API inafikika, kisha uiondoe na urekebishe njia ya kitatuzi; kuiacha mahali panabadilisha swali la njia kuwa uwindaji wa hazina baadaye. Chaguo lolote utakalochagua, andika eneo, anwani ya kitatuzi na njia inayobeba ombi.

Jaribu kituo cha API, si jina pekee

Utafutaji ukifaulu, pata kituo cha toleo la API kwa CA ya kundi. curl --cacert ca.crt https://api.internal.example:6443/version hutenganisha kushindwa kwa TLS na idhini na DNS. 403 inamaanisha jina na muunganisho hufanya kazi na utambulisho haufanyi.

Pia angalia kama safu ya anwani za mteja inaruhusiwa na mitandao iliyoidhinishwa au firewall ya kundi. Makundi ya kibinafsi mara nyingi hukubali trafiki ya API kutoka VNet au safu za peer pekee, kwa hivyo tuneli inayogawa anwani kutoka dimbwi lingine huunganisha kwenye tabaka la mtandao na hutupwa kwenye API.

Andika mambo manne unapopandisha: kitatuzi ambacho mteja alitumia, anwani iliyorudisha, URL ya seva katika muktadha wa kubeconfig uliochaguliwa, na operesheni ya kwanza iliyoshindwa. Rekodi hiyo inamwambia mhandisi anayefuata kama abadilishe DNS, njia au sera ya firewall, na inazuia uhariri unaofuata wa faili ya hosts.

Anza na utafutaji, chagua njia ya kitatuzi inayolingana na mwenye eneo, kisha thibitisha kituo. Ikiwa yote matatu yatapita, tatizo lililobaki ni idhini, si utatuzi wa majina.