kubectl-ը չի կարող լուծել մասնավոր կլաստերի API-ն OpenVPN-ով

kubectl-ը ձախողվում է անվան որոնման ժամանակ, մինչ թունելը միացված է, և API-ի մասնավոր հասցեն դեռ պատասխանում է ping-ին։ Երթուղին կարգին է. հաճախորդը հարցնում է լուծիչի, որը երբեք չի լսել կլաստերի մասնավոր գոտու մասին։ Ամենից հաճախ օգտագործում են երկու ուղղում՝ վիրտուալ ցանցի լուծիչն ուղարկել յուրաքանչյուր VPN հաճախորդի, կամ անունը տեղում ամրացնել hosts գրառմամբ կամ պայմանական վերահասցեավորիչով։ Նրանք լուծում են նույն ախտանիշը տարբեր պատասխանատվությամբ, և դրանք շփոթելը հանգեցնում է նրան, որ թիմերը hosts ֆայլերը խմբագրում են ամեն անգամ, երբ վերջնակետը վերակառուցվում է։

Լուծումը և հասանելիությունը ձախողվում են տարբեր շերտերում

Ինքներդ կատարեք որոնումը, նախքան որևէ բան փոխելը։ getent hosts-ը Linux-ում կամ nslookup-ը Windows-ում ասում է՝ հաճախորդն ընդհանրապես պատասխան ստանում է, թե ոչ. ժամանակի սպառումը կամ NXDOMAIN-ը մատնանշում են լուծիչը, իսկ սխալ հասցեով պատասխանը՝ հնացած գրառում կամ հանրային անցում։

Այնուհետև հաստատեք, թե որ սերվերին է kubectl-ը իրականում միանում. kubeconfig համատեքստը պահում է URL, և VPN երթուղին այն չի վերագրում։ Եթե համատեքստը նշում է հանրային վերջնակետ, DNS-ը կարող է կատարյալ լինել, և հրամանը միևնույն է ձախողվի։

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

Երրորդ ազդանշանը որոնումից հետո ձախողման ձևն է։ Անուն, որը լուծվում է մասնավոր հասցեի և հետո ստանում TCP ժամանակի սպառում, firewall-ի կամ լիազորված ցանցի խնդիր է։ Անուն, որը լուծվում է հանրային հասցեի, նշանակում է, որ հարցումը դուրս է եկել մասնավոր գոտուց։ Այս երեք արդյունքները պահեք առանձին. յուրաքանչյուրը ձեզ տանում է այլ պատասխանատուի մոտ։

Տարբերակ A. վիրտուալ ցանցի լուծիչն ուղարկել թունել

Երբ VPN սերվերը աշխատում է վիրտուալ ցանցի ներսում, հաճախորդները կարող են օգտագործել նույն լուծիչը, ինչ սերվերի հոսթը։ OpenVPN Community-ում սերվերը DNS տարբերակ է ուղարկում. Access Server-ը նույն կարգավորումը ցույց է տալիս ադմինիստրատիվ ինտերֆեյսում, և հաճախորդները պետք է նորից ներբեռնեն պրոֆիլը, քանի որ DNS հրահանգը ճամփորդում է դրա ներսում։

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

Երթուղու տողը կարևոր է split tunnel պրոֆիլներում։ Լուծիչի հասցե ուղարկելը նույնը չէ, ինչ այն հասանելի դարձնելը. եթե թունելով անցնում է միայն կլաստերի ենթացանցը, 10.0.0.4-ի հարցումը դուրս է գալիս տեղական LAN-ով և մահանում։ Ուղարկեք հոսթի երթուղի լուծիչի համար, կամ ներառեք դրա ենթացանցը թունելում։

Ընդունող կողմն էլ ունի քաղաքականություն։ Հաճախորդի հասցեների տիրույթից հասանելի լուծիչը դեռ կարող է մերժել այնտեղից եկող հարցումները, և վիրտուալ ցանցին կապված մասնավոր գոտին պատասխանում է միայն այն հաճախորդներին, որոնք գալիս են այդ ցանցի DNS ուղով։ Եթե ուղարկելուց հետո որոնումը սպառվում է, նախքան հաճախորդին նորից դիպչելը նայեք լուծիչի սեփական մատյանները։

Հաճախորդի վրա ստուգեք, թե ինչ է կիրառվել. resolvectl status systemd-resolved Linux-ում, scutil --dns macOS-ում, ipconfig /all Windows-ում։ Ուղարկված DNS սերվեր, որը երբեք չի հայտնվում, նշանակում է, որ պրոֆիլը նորից չի բեռնվել։

Տարբերակ B. hosts գրառումներ և պայմանական վերահասցեավորում

hosts գրառումը ամենափոքր հնարավոր ուղղումն է և ամենափխրունը։ Այն մեկ անունը կապում է մեկ մեքենայի մեկ հասցեի հետ, ուստի աշխատում է ցուցադրության համար և կոտրվում, երբ մասնավոր վերջնակետը կամ դրա IP-ն վերակառուցվում է։ Այն նաև թաքցնում է իրական բացը մնացած թիմից։

Պայմանական վերահասցեավորիչն ավելի լավ է մասշտաբվում՝ առանց DNS-ը յուրաքանչյուր հաճախորդի ուղարկելու։ dnsmasq-ը կարող է մեկ գոտի ուղարկել VNet-ի լուծիչին և մնացածը հանգիստ թողնել. server=/cluster.internal/10.0.0.4։ Windows DNS-ն ունի պայմանական վերահասցեավորիչներ, և Windows հաճախորդները կարող են NRPT կանոն օգտագործել նույն բաժանման համար։ Վերահասցեավորիչը դեռ պետք է երթուղի դեպի VNet-ի լուծիչ։

Վերահասցեավորումը սովորական դիտարկումը պահում է տեղական, ինչը կարևոր է split tunnel-ում։ Այն ձեզ տալիս է մեկ տեղ մասնավոր գոտու հարցումները գրանցելու և մեկ տեղ, որը կոտրվում է, երբ վերահասցեավորիչի հոսթը տեղափոխվում է։

Ընտրեք ըստ պատասխանատվության, ոչ թե հարմարության

Ուղարկեք լուծիչը, երբ կառավարում եք VPN պրոֆիլը և ուզում եք, որ աշխատի յուրաքանչյուր մասնավոր անուն, ոչ միայն API-ն։ Ընտրեք վերահասցեավորիչ, երբ հաճախորդները պետք է պահեն տեղական DNS-ը մնացած ամեն ինչի համար, կամ երբ VPN-ը ղեկավարում է կլաստերից տարբեր թիմ։

hosts գրառումները ախտորոշում են, ոչ տեղակայում։ Օգտագործեք մեկը՝ ապացուցելու, որ API-ն հասանելի է, ապա հեռացրեք և ուղղեք լուծիչի ուղին. այն թողնելը հետագայում երթուղային հարցը դարձնում է գանձի որոնում։ Ինչ տարբերակ էլ ընտրեք, գրի առեք գոտին, լուծիչի հասցեն և այն երթուղին, որը կրում է հարցումը։

Ստուգեք API-ի վերջնակետը, ոչ միայն անունը

Երբ որոնումը հաջողվում է, ստացեք API-ի տարբերակի վերջնակետը կլաստերի CA-ով։ curl --cacert ca.crt https://api.internal.example:6443/version-ը առանձնացնում է TLS-ի և լիազորման ձախողումները DNS-ից։ 403-ը նշանակում է, որ անունն ու կապը աշխատում են, իսկ ինքնությունը՝ ոչ։

Ստուգեք նաև, թե արդյոք հաճախորդի հասցեների տիրույթը թույլատրված է կլաստերի լիազորված ցանցերով կամ firewall-ով։ Մասնավոր կլաստերները հաճախ API երթևեկությունն ընդունում են միայն VNet-ից կամ peered տիրույթներից, ուստի այլ լողավազանից հասցեներ տվող թունելը միանում է ցանցային շերտում և մերժվում API-ում։

Էսկալացնելիս գրի առեք չորս փաստ. այն լուծիչը, որն օգտագործել է հաճախորդը, այն հասցեն, որը նա վերադարձրել է, սերվերի URL-ը ընտրված kubeconfig համատեքստում և առաջին ձախողված գործողությունը։ Այդ գրառումը հաջորդ ինժեներին ասում է՝ փոխե՞լ DNS-ը, երթուղավորումը, թե firewall-ի քաղաքականությունը, և դադարեցնում է hosts ֆայլի հաջորդ խմբագրումը։

Սկսեք որոնումից, ընտրեք լուծիչի այն ուղին, որը համապատասխանում է գոտու սեփականատիրոջը, ապա ստուգեք վերջնակետը։ Եթե երեքն էլ անցնեն, մնացած խնդիրը լիազորումն է, ոչ անվան լուծումը։