kubectl không thể phân giải API của cụm riêng tư qua OpenVPN

kubectl thất bại khi tra tên trong lúc đường hầm đang hoạt động và địa chỉ riêng của API vẫn trả lời ping. Tuyến đường vẫn đúng; máy khách đang hỏi một bộ phân giải chưa từng nghe về vùng riêng của cụm. Hai cách sửa được dùng nhiều nhất: đẩy bộ phân giải của mạng ảo tới từng máy khách VPN, hoặc ghim tên cục bộ bằng một mục hosts hay một bộ chuyển tiếp có điều kiện. Chúng xử lý cùng một triệu chứng với quyền sở hữu khác nhau, và việc lẫn lộn hai cách là lý do các nhóm phải sửa tệp hosts mỗi khi điểm cuối được dựng lại.

Phân giải và khả năng tiếp cận thất bại ở các tầng khác nhau

Hãy tự chạy tra cứu trước khi thay đổi bất cứ điều gì. getent hosts trên Linux hoặc nslookup trên Windows cho bạn biết máy khách có nhận được câu trả lời hay không; hết thời gian chờ hoặc NXDOMAIN chỉ vào bộ phân giải, còn câu trả lời sai địa chỉ chỉ vào một bản ghi cũ hoặc một lối thoát công khai.

Sau đó xác nhận kubectl thực sự kết nối tới máy chủ nào. Ngữ cảnh kubeconfig lưu một URL, và tuyến VPN không ghi đè nó: nếu ngữ cảnh nêu một điểm cuối công khai, DNS có thể hoàn hảo mà lệnh vẫn thất bại.

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

Tín hiệu thứ ba là hình dạng của lỗi sau khi tra cứu. Một tên phân giải ra địa chỉ riêng rồi gặp hết thời gian chờ TCP là vấn đề tường lửa hoặc mạng được cấp quyền. Một tên phân giải ra địa chỉ công khai nghĩa là truy vấn đã thoát khỏi vùng riêng. Hãy tách ba kết quả đó; mỗi kết quả dẫn bạn tới một người phụ trách khác.

Phương án A: đẩy bộ phân giải của mạng ảo vào đường hầm

Khi máy chủ VPN chạy trong mạng ảo, máy khách có thể dùng cùng bộ phân giải với máy chủ. Trong OpenVPN Community máy chủ đẩy một tùy chọn DNS; Access Server hiển thị cùng thiết lập đó trong giao diện quản trị, và máy khách phải tải lại hồ sơ vì chỉ thị DNS đi kèm trong đó.

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

Dòng tuyến đường quan trọng với hồ sơ split tunnel. Đẩy một địa chỉ bộ phân giải không giống như làm cho nó tiếp cận được: nếu chỉ có mạng con của cụm đi qua đường hầm, truy vấn tới 10.0.0.4 sẽ ra khỏi LAN cục bộ và chết. Hãy đẩy một tuyến máy chủ cho bộ phân giải, hoặc đưa mạng con của nó vào đường hầm.

Phía nhận cũng có chính sách. Một bộ phân giải tiếp cận được từ dải địa chỉ của máy khách vẫn có thể từ chối các truy vấn từ đó, và một vùng riêng liên kết với mạng ảo chỉ trả lời những máy khách đến qua đường DNS của mạng đó. Nếu tra cứu hết thời gian chờ sau khi đẩy, hãy xem nhật ký của chính bộ phân giải trước khi chạm vào máy khách lần nữa.

Trên máy khách, hãy kiểm chứng điều gì đã được áp dụng: resolvectl status trên Linux systemd-resolved, scutil --dns trên macOS, ipconfig /all trên Windows. Một máy chủ DNS được đẩy mà không bao giờ xuất hiện nghĩa là hồ sơ chưa được tải lại.

Phương án B: mục hosts và chuyển tiếp có điều kiện

Một mục hosts là cách sửa nhỏ nhất có thể và cũng dễ vỡ nhất. Nó ánh xạ một tên tới một địa chỉ trên một máy, nên nó hợp cho bản demo và sẽ hỏng khi điểm cuối riêng hoặc IP của nó được dựng lại. Nó cũng che giấu khoảng trống thật với phần còn lại của nhóm.

Một bộ chuyển tiếp có điều kiện mở rộng tốt hơn mà không phải đẩy DNS tới mọi máy khách. dnsmasq có thể gửi một vùng tới bộ phân giải của VNet và để mọi thứ khác yên: server=/cluster.internal/10.0.0.4. DNS của Windows có bộ chuyển tiếp có điều kiện, và máy khách Windows có thể dùng quy tắc NRPT cho cùng cách tách đó. Bộ chuyển tiếp vẫn cần một tuyến tới bộ phân giải của VNet.

Việc chuyển tiếp giữ duyệt web bình thường ở cục bộ, điều này có ý nghĩa với split tunnel. Nó cũng cho bạn một chỗ để ghi nhật ký truy vấn cho vùng riêng, và một chỗ sẽ hỏng khi máy chủ chuyển tiếp di chuyển.

Hãy chọn theo quyền sở hữu, không theo sự tiện lợi

Hãy đẩy bộ phân giải khi bạn kiểm soát hồ sơ VPN và muốn mọi tên riêng hoạt động, không chỉ API. Hãy chọn bộ chuyển tiếp khi máy khách phải giữ DNS cục bộ cho mọi thứ khác, hoặc khi VPN do một nhóm khác với cụm quản lý.

Mục hosts là chẩn đoán, không phải triển khai. Hãy dùng một mục để chứng minh API tiếp cận được, rồi gỡ nó và sửa đường của bộ phân giải; để nguyên nó sẽ biến một câu hỏi định tuyến thành cuộc săn kho báu về sau. Dù chọn phương án nào, hãy ghi lại vùng, địa chỉ bộ phân giải và tuyến đường mang truy vấn.

Hãy kiểm tra điểm cuối API, không chỉ tên

Khi tra cứu thành công, hãy lấy điểm cuối phiên bản của API bằng CA của cụm. curl --cacert ca.crt https://api.internal.example:6443/version tách lỗi TLS và lỗi cấp quyền khỏi DNS. Một 403 nghĩa là tên và kết nối hoạt động còn danh tính thì không.

Cũng hãy kiểm tra xem dải địa chỉ của máy khách có được các mạng được cấp quyền hoặc tường lửa của cụm cho phép không. Các cụm riêng thường chỉ nhận lưu lượng API từ VNet hoặc các dải peered, nên một đường hầm cấp địa chỉ từ một nhóm khác sẽ kết nối ở tầng mạng và bị loại ở API.

Hãy ghi bốn dữ kiện khi bạn chuyển cấp: bộ phân giải mà máy khách đã dùng, địa chỉ nó trả về, URL máy chủ trong ngữ cảnh kubeconfig đã chọn, và thao tác đầu tiên thất bại. Bản ghi đó cho kỹ sư tiếp theo biết nên đổi DNS, định tuyến hay chính sách tường lửa, và nó chặn lần sửa tệp hosts tiếp theo.

Hãy bắt đầu bằng tra cứu, chọn đường của bộ phân giải khớp với người sở hữu vùng, rồi kiểm chứng điểm cuối. Nếu cả ba đều qua, vấn đề còn lại là cấp quyền, không phải phân giải tên.