kubectl нь OpenVPN-оор дамжуулан хувийн кластерын API-г шийдэж чадахгүй

kubectl нь туннель ажиллаж, API-ийн хувийн хаяг ping-д хариу үйлдэл үзүүлсээр байхад нэр хайлтад бүтэлгүйтдэг. Зам зөв; клиент кластерын хувийн бүсийн тухай хэзээ ч сонсоогүй шийдэгчээс асууж байна. Хамгийн их хэрэглэгддэг хоёр засвар: виртуал сүлжээний шийдэгчийг VPN клиент бүрт илгээх, эсвэл нэрийг hosts бичлэг эсвэл нөхцөлт дамжуулагчаар локалаар бэхлэх. Тэд ижил шинж тэмдгийг өөр хариуцлагаар шийддэг бөгөөд тэдгээрийг холих нь багууд эцсийн цэг дахин бүтээгдэх бүрт hosts файлыг засварлахад хүргэдэг.

Шийдэлт ба хүртээмж өөр давхаргад бүтэлгүйтдэг

Ямар нэг зүйлийг өөрчлөхөөс өмнө хайлтыг өөрөө хий. Linux дээр getent hosts эсвэл Windows дээр nslookup нь клиент ерөнхийдөө хариу авч байгаа эсэхийг хэлнэ; хугацаа дуусах эсвэл 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 хугацаа дуусалт тохиолдвол энэ нь галт хана эсвэл зөвшөөрөгдсөн сүлжээний асуудал. Нийтийн хаяг руу шийдэгдсэн нэр нь асуулга хувийн бүсээс гарсан гэсэн үг. Эдгээр гурван үр дүнг тусдаа бариарай; тус бүр өөр хариуцагч руу хөтөлнө.

А хувилбар: виртуал сүлжээний шийдэгчийг туннель руу илгээ

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 замаар ирсэн клиентүүдэд хариулна. Хэрэв хайлт илгээсний дараа хугацаа дуусаж байвал клиентэд дахин хүрэхээс өмнө шийдэгчийн өөрийн логыг шалга.

Клиент дээр юу хэрэглэгдсэнийг шалга: systemd-resolved Linux дээр resolvectl status, macOS дээр scutil --dns, Windows дээр ipconfig /all. Илгээсэн DNS сервер хэзээ ч харагдахгүй бол профайл дахин ачаалагдаагүй гэсэн үг.

Б хувилбар: 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 нь нэр, холболт ажиллаж байгаа, харин таних тэмдэг ажиллахгүй байгааг илэрхийлнэ.

Мөн клиентийн хаягийн мужийг кластерын зөвшөөрөгдсөн сүлжээ эсвэл галт хана зөвшөөрч байгаа эсэхийг шалга. Хувийн кластерууд ихэвчлэн API урсгалыг зөвхөн VNet эсвэл peer мужуудаас хүлээн авдаг тул өөр усан сангаас хаяг олгосон туннель сүлжээний давхаргад холбогдоод API дээр хасагдана.

Эскалац хийхдээ дөрвөн баримтыг бич: клиентийн ашигласан шийдэгч, түүний буцаасан хаяг, сонгосон kubeconfig контекст дахь серверийн URL, бүтэлгүйтсэн эхний үйлдэл. Тэр бичлэг дараагийн инженерд DNS, зам эсвэл галт хананы бодлогыг өөрчлөх эсэхийг хэлж, дараагийн hosts файлын засварыг зогсоодог.

Хайлтаас эхэлж, бүсийн эзэмшигчид тохирох шийдэгчийн замыг сонгоод, дараа нь эцсийн цэгийг шалга. Гурвуулаа давбал үлдсэн асуудал нь зөвшөөрөл, нэр шийдэлт биш.