IP của máy khách VPN trong Kubernetes: giữ nguyên hay SNAT?

Ở đâu đó giữa đường hầm và backend, địa chỉ của máy khách hoặc sống sót hoặc bị thay thế, và cả hai kết cục đều có lý. Lựa chọn thuộc về chủ sở hữu dịch vụ nhận, không phải người đã cài CNI. Khi việc cấp quyền theo từng máy khách, hạn mức hoặc bản ghi kiểm toán quan trọng, địa chỉ phải sống sót qua từng chặng. Khi việc quy trách nhiệm chung là chấp nhận được, NAT nguồn loại bỏ một vấn đề định tuyến mà nếu không bạn sẽ phải duy trì mãi mãi.

Địa chỉ của máy khách thực sự biến mất ở đâu

Gói tin của một máy khách từ xa đến pod VPN với nguồn bên trong nằm trong dải đường hầm, giả sử 10.90.0.42. Khi pod chuyển tiếp gói đó về phía ClusterIP hoặc IP của pod, ba cơ chế khác nhau có thể viết lại nguồn. Quy tắc masquerade của CNI trên node bao trùm lưu lượng mà pod gửi ra ngoài CIDR của cụm. Mục conntrack của kube-proxy trên node đích bao trùm chính chặng tới Service. Một proxy kết thúc kết nối hoàn toàn không chuyển tiếp gói, nên nguồn mà cuối cùng bạn thấy thuộc về proxy.

Mỗi thứ sống trong một tầng khác nhau, nên một trường Service gần như không bao giờ sửa được toàn bộ đường đi.

externalTrafficPolicy trên Service công khai của VPN chỉ quyết định điều gì xảy ra với kết nối bên ngoài: Local giữ địa chỉ từ xa trên node đã nhận nó, trong khi Cluster cho phép kube-proxy giao gói cho node khác và masquerade nó ở đó. Cấu hình đó điều khiển listener mà máy khách của bạn kết nối tới. Nó không nói gì về gói đã giải mã mà tiến trình VPN của bạn sau đó định tuyến vào cụm.

Ba điều kiện kết thúc cuộc tranh luận

Tôi đặt cùng ba câu hỏi theo cùng thứ tự mỗi khi vấn đề này xuất hiện, vì câu đầu thường kết thúc cuộc thảo luận. Hãy trả lời cho khối lượng công việc cụ thể chứ không phải cho cả cụm. Hai cụm trong cùng một công ty có thể đi đến câu trả lời khác nhau và cả hai đều đúng.

Nếu backend trả lời có cho câu hỏi đầu và không cho câu thứ hai, bạn có việc mạng phải làm chứ không phải sửa manifest. Nếu dòng thứ ba nói proxy, địa chỉ đã không bao giờ sống sót, và việc giả vờ ngược lại tốn một tuần bắt gói.

Chế độ preserve đòi hỏi gì ở mạng

Giữ nguồn nghĩa là node đích phải gửi lưu lượng trở lại 10.90.0.42 qua một gateway VPN đang hoạt động. Bể VPN không phải CIDR của cụm, nên không CNI nào định tuyến nó thay bạn theo mặc định. Bạn tự thêm tuyến, rồi bảo đảm điểm cuối gateway mà nó trỏ tới sống sót qua một lần lập lịch lại.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Chặng tiếp theo là địa chỉ pod, và địa chỉ pod di chuyển. Trỏ tuyến vào VIP của Service hoặc địa chỉ node cố định, hoặc chấp nhận rằng bạn sẽ đuổi theo gateway sau mỗi lần bị trục xuất. Lọc đường ngược là cái bẫy khác: chế độ nghiêm ngặt bỏ các gói có đường quay về không khớp với giao diện mà chúng đi vào, và đó chính xác là hình dạng của một luồng VPN được giữ nguyên.

Việc kiểm tra lỏng lẻo thường là khác biệt giữa một đường quay về hoạt động và những câu trả lời biến mất sau khi rời backend. Các quy tắc masquerade trên node VPN cũng phải loại trừ dải đường hầm, nếu không gói được chuyển tiếp sẽ ra đi với địa chỉ của pod, bất kể bạn đã xây tuyến nào. Nên diễn đạt việc loại trừ đó trong cấu hình của chính CNI thay vì sửa iptables bằng tay, vì agent viết lại các chuỗi của nó khi khởi động lại và quy tắc bạn viết tay chỉ tồn tại đúng đến lần nâng cấp tiếp theo.

NetworkPolicy là kiểm soát truy cập, không phải định tuyến. Siết chặt một chính sách sẽ không bao giờ khôi phục một địa chỉ mà masquerade đã thay thế.

SNAT tốn gì, và làm sao để ghi lại

NAT nguồn về phía cụm là thiết kế rẻ hơn, và đó không phải sai lầm. Backend thấy địa chỉ pod hoặc node VPN, các bản ghi khớp nhau, và không cần tồn tại tuyến quay về. Điều bạn mất là khả năng phân biệt hai máy khách ở tầng mạng, nên hạn mức, lệnh cấm và dấu vết kiểm toán phải đến từ nơi khác.

Thường thì nơi khác đó là ứng dụng: một token phiên, một tiêu đề đã ký, hoặc một dòng giao thức PROXY do proxy bạn kiểm soát ghi ra. Những thứ này cho người nhận một danh tính chỉ đáng tin khi proxy nằm trên đường đi và tiêu đề không thể được đặt từ phía máy khách. Hãy nói rõ trong runbook là cái nào áp dụng, vì kỹ sư tiếp theo sẽ giả định địa chỉ trong bản ghi là máy khách. Nó không phải, và một sự cố là đủ để làm giả định đó trở nên đắt giá.

Sự đánh đổi vẫn trung thực chừng nào nó còn được ghi lại.

Những kiểm tra phân biệt một đường đi hoạt động với một đường đi may mắn

Hãy thử với kết nối mới thay vì kết nối đã lưu đệm, và thử theo cả hai chiều. Một số lỗi chỉ trông chập chờn vì các luồng mới đi theo đường đã bị viết lại.

Bắt tuple tại ba điểm trong một yêu cầu được cấp quyền: ngay sau khi giải mã, trên giao diện ra của pod VPN, và trên backend. Nếu nguồn thay đổi giữa lần bắt thứ hai và thứ ba, nguyên nhân nằm ở phía dưới pod. Nếu thay đổi trước lần thứ hai, chính pod đang dịch.

Sau đó xóa pod VPN và lặp lại thử nghiệm trong khi nó được lập lịch lại. Một đường được giữ nguyên mà vỡ khi bị trục xuất là chưa hoàn chỉnh, và một quy tắc NAT ghim vào địa chỉ không còn tồn tại cũng vậy. Cuối cùng, gửi một yêu cầu từ một nguồn mà bạn mong bị từ chối và xác nhận rằng sự từ chối đến từ chính sách chứ không phải từ một tuyến bị thiếu.