Điểm:1

Hết thời gian chờ trên Cloud SQL và các dịch vụ bên ngoài khác khi sử dụng NAT + IP Masquerade trên GKE

lá cờ it

Tôi phải định cấu hình IP tĩnh ở một trong các POD của mình vì dịch vụ từ xa (bên ngoài cụm của tôi) yêu cầu danh sách trắng IP đáng tin cậy.

Tôi đã làm theo tài liệu do Google cung cấp:

https://cloud.google.com/nat/docs/overview?hl=es-419

https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent

Nhưng khi cố gắng định cấu hình lưu lượng truy cập bằng cách sử dụng dịch vụ NAT trên đám mây của Google trong cụm GKE của tôi cộng với giả mạo bằng cách sử dụng đại lý ip-masq Tôi bắt đầu hết thời gian chờ và gặp sự cố khi truy cập các dịch vụ từ xa bên ngoài cụm.

Cụm của tôi đang ở phiên bản 1.19.10-gke.1600.

Tôi đã thử các tệp cấu hình này với kết quả như sau:

resyncInterval: 60s

Kết quả:

Chuỗi IP-MASQ (2 tài liệu tham khảo)
đích prot opt ​​nguồn đích         
TRẢ LẠI tất cả -- bất kỳ đâu 10.0.0.0/8 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất kỳ đâu 172.16.0.0/12 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.168.0.0/16 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
MASQUERADE tất cả -- mọi nơi mọi nơi /* ip-masq-agent: lưu lượng truy cập đi là phụ
đề cập đến MASQUERADE (phải là người cuối cùng trong chuỗi) */

Các dịch vụ tiếp tục sử dụng sai IP.


resyncInterval: 60s
masqLinkLocal: đúng

Chuỗi IP-MASQ (2 tài liệu tham khảo)
đích prot opt ​​nguồn đích         
TRẢ LẠI tất cả -- bất kỳ đâu 169.254.0.0/16 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất kỳ đâu 10.0.0.0/8 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất kỳ đâu 172.16.0.0/12 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.168.0.0/16 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
MASQUERADE tất cả -- mọi nơi mọi nơi /* ip-masq-agent: lưu lượng truy cập đi là phụ
đề cập đến MASQUERADE (phải là người cuối cùng trong chuỗi) */

Hiệu ứng tương tự, các dịch vụ bên ngoài của tôi nhận sai IP.


nonMasqueradeCIDRs:
  - 0.0.0.0/0
resyncInterval: 60s
masqLinkLocal: đúng

Chuỗi IP-MASQ (2 tài liệu tham khảo)
đích prot opt ​​nguồn đích         
TRẢ LẠI tất cả -- mọi nơi mọi nơi /* ip-masq-agent: lưu lượng truy cập cục bộ không phụ
từ chối MASQUERADE */
MASQUERADE tất cả -- mọi nơi mọi nơi /* ip-masq-agent: lưu lượng truy cập đi là phụ
đề cập đến MASQUERADE (phải là người cuối cùng trong chuỗi) */

Có vẻ như điều này hoạt động tốt hơn vì các dịch vụ bên ngoài nhận được đúng IP nhưng tôi gặp sự cố kết nối và hết thời gian chờ.


Đây là cấu hình NAT của tôi:

lập bản đồ NAT
- Tính khả dụng cao: Có
- Mạng con nguồn & dải IP: Tất cả dải IP chính và phụ của mạng con
- Địa chỉ IP NAT: static-egress-ip XXX.XXX.XXX.XXX

Tôi hết ý tưởng, ai đó có thể cho tôi lời khuyên không?


Sau khi có phản hồi ở đây, tôi đã cập nhật tệp cấu hình của mình để thêm ips theo tài liệu đám mây của Google, tệp sẽ như sau:

nonMasqueradeCIDRs:
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
  - 100.64.0.0/10
  - 192.0.0.0/24
  - 192.0.2.0/24
  - 192.88.99.0/24
  - 198.18.0.0/15
  - 198.51.100.0/24
  - 203.0.113.0/24
  - 240.0.0.0/4
resyncInterval: 60s
masqLinkLocal: đúng

Kết quả của việc này trong iptables là:

Chuỗi IP-MASQ (2 tài liệu tham khảo)
đích prot opt ​​nguồn đích         
TRẢ LẠI tất cả -- bất kỳ đâu 10.0.0.0/8 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất kỳ đâu 172.16.0.0/12 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.168.0.0/16 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất kỳ đâu 100.64.0.0/10 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.0.0.0/24 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.0.2.0/24 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 192.88.99.0/24 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 198.18.0.0/15 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 198.51.100.0/24 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 203.0.113.0/24 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
TRẢ LẠI tất cả -- bất cứ đâu 240.0.0.0/4 /* ip-masq-agent: lưu lượng cục bộ không phụ
từ chối MASQUERADE */
MASQUERADE tất cả -- mọi nơi mọi nơi /* ip-masq-agent: lưu lượng truy cập đi là phụ
đề cập đến MASQUERADE (phải là người cuối cùng trong chuỗi) */

Nhưng nếu tôi chạy một curl checkip.amazonaws.com để xem nút nào đang được nút sử dụng, tôi lấy một IP khác với IP được xác định trong cấu hình NAT Cloud của tôi và các dịch vụ bên ngoài từ chối yêu cầu là không đáng tin cậy từ cụm của tôi.

Điểm:1
lá cờ gh

Có vẻ như bạn đã đặt nonMasqueradeCIDRs: là 0.0.0.0/0, do đó ngăn việc Giả mạo tất cả lưu lượng CIDR, vì vậy, để khắc phục sự cố này, trong tệp cấu hình, hãy cập nhật khóa nonMasqueradeCIDRs: với các IP được đề cập trong đoạn đích không giả mạo Defaut [1] như được đưa ra bên dưới.

nonMasqueradeCIDRs:

  • 172.16.0.0/12
  • 192.168.0.0/16
  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4
  • 10.0.0.0/8

Ngoài ra, xin lưu ý rằng các IP được đề cập trong ảnh chụp màn hình không phải là IP sai nhưng đó là các dải được dành riêng bởi RFC 1918/link-local, tức là các IP 10.0.0.0/8, 172.16.0.0/12 192.168.0.0/16 được dành riêng cho RFC 1918 và dải IP 169.254.0.0/16 được dành riêng cho liên kết cục bộ và những IP này không thể giả mạo được và do đó các IP này đang được hiển thị với mô tả âip-masq-agent: lưu lượng truy cập cục bộ không bị giả mạoâ [2].

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#default-non-masq-dests

[2] https://kubernetes.io/docs/tasks/administer-cluster/ip-masq-agent/#ip-masquerade-agent-user-guide

Trân trọng, Anbu.

lá cờ it
Xin chào @Anbu, cảm ơn rất nhiều vì sự giúp đỡ. Tôi đã làm theo hướng dẫn của bạn và thay vì sử dụng 0.0.0.0/0 như masq, tôi đặt các phạm vi được xác định trong tài liệu. Bạn có thể xem các phiên bản được thực hiện cho câu hỏi của tôi để xem đầu ra của các lệnh nhưng tôi vẫn gặp sự cố là các nút và nhóm của tôi đang gọi các dịch vụ bên ngoài bằng IP mà tôi không kiểm soát. IP cố định NAT mà tôi đã định cấu hình trong GOOGLE CLOUD NAT bị bỏ qua. Tôi đang thử nghiệm điều này với một cuộn tròn trực tiếp từ nút ssh hoặc gọi các dịch vụ bên ngoài của tôi sẽ trả lại IP không được phép. Bất kỳ ý tưởng?
Điểm:0
lá cờ it

Cuối cùng chúng tôi đã có thể chẩn đoán vấn đề. Cụm của chúng tôi đã được tạo cách đây một thời gian khi GCP không hỗ trợ các cụm riêng tư nên cụm của chúng tôi là công khai.

Mỗi nút có một IP tạm thời công khai, do đó các quy tắc NAT đang bị bỏ qua.

Giải pháp là đặt một nút có IP tĩnh chứ không phải tạm thời và định cấu hình khối lượng công việc yêu cầu xác thực đáng tin cậy để luôn triển khai trên nút cụ thể đó. Đây không phải là một giải pháp hoàn hảo nhưng là những gì chúng ta có thể làm nhanh chóng để giải quyết vấn đề.

Giải pháp thực sự sẽ là di chuyển sang cụm riêng tư và định cấu hình NAT nhưng thật đáng buồn là GCP không hỗ trợ di chuyển từ cụm công khai sang cụm riêng tư. Tùy chọn duy nhất sẽ là tạo một cụm mới và di chuyển khối lượng công việc sang cụm mới, quy trình mà chúng tôi sẽ cần thực hiện trong thời gian ngắn.

Có thể đây là thời điểm tốt để thử nghiệm chế độ lái tự động không hỗ trợ tự động di chuyển.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.