Tôi đang cố gắng thực hiện một yêu cầu cục bộ tới cụm kubernetes được lưu trữ trên máy chủ của tôi, NodePort của cụm đang lắng nghe tại địa chỉ sau 172.20.120.1:30280. Khách hàng bên ngoài trong quá trình sản xuất được yêu cầu đưa ra yêu cầu đối với 172.20.0.1:8000 (điều này không thể thay đổi), vì vậy tôi đang cố gắng thêm quy tắc DNAT vào lưu lượng truy cập từ:
172.20.0.1:8000 -> 172.20.120.1:30280 (K8s NodePort)
Tôi đã thêm quy tắc DNAT PREROUTING sau:
PREROUTING chuỗi (chính sách CHẤP NHẬN 2614 gói, 170K byte)
num pkts byte target prot opt in out đích nguồn
...
26 27462 1648K DNAT tcp -- * * 0.0.0.0/0 172.20.0.1 tcp dpt:8000 đến:172.20.120.1:30280
và quy tắc OUTPUT sau:
# iptables -v -L OUTPUT -n --line-numbers | đầu -10
ĐẦU RA chuỗi (chính sách CHẤP NHẬN 0 gói, 0 byte)
num pkts byte target prot opt in out đích nguồn
...
4 943 156K tcp -- * * 0.0.0.0/0 172.20.120.1 tcp dpt:30280
Tôi có thể thực hiện yêu cầu cuộn tròn 172.20.120.1:30280 trực tiếp và nhận được phản hồi thành công trở lại. Tuy nhiên, khi tôi thực hiện một yêu cầu cuộn tròn 172.20.0.1:8000 nó chỉ bị treo với thông báo sau:
# cuộn tròn -vvvk https://172.20.0.1:8000/v1/my-api
* Sắp kết nối() với cổng 172.20.0.1 8000 (#0)
* Đang thử 172.20.0.1...
* Đã kết nối với cổng 172.20.0.1 (172.20.0.1) 8000 (#0)
* Khởi tạo NSS với certpath: sql:/etc/pki/nssdb
Và rồi nó cuối cùng cũng hết thời gian.
Tcpdump của tôi cho thấy rằng lưu lượng truy cập đang được chuyển tiếp đến đúng IP đó khi kích hoạt yêu cầu cuộn tròn tới 172.20.0.1:8000:
# tcpdump -nnvvv -i bất kỳ src 172.20.0.1 và dst 172.20.120.1
tcpdump: lắng nghe trên bất kỳ loại LINUX_SLL loại liên kết nào (Linux đã nấu chín), kích thước chụp 262144 byte
08:47:07.108364 IP (tos 0x0, ttl 64, id 27172, offset 0, flags [DF], TCP nguyên mẫu (6), chiều dài 60)
172.20.0.1.52910 > 172.20.120.1.30280: Flags [S], cksum 0xd85d (không chính xác -> 0x84e2), seq 1825443523, win 43690, tùy chọn [mss 65495,sackOK,TS val 549020903 ecr 0,nop,wscale , chiều dài 0
08:47:07.108771 IP (tos 0x0, ttl 64, id 27173, offset 0, flags [DF], TCP nguyên mẫu (6), chiều dài 52)
172.20.0.1.52910 > 172.20.120.1.30280: Flags [.].
08:47:07.206994 IP (tos 0x0, ttl 64, id 27174, offset 0, flags [DF], TCP nguyên mẫu (6), chiều dài 229)
...
Ngoài ra, tôi đã thêm TRACE vào các quy tắc iptable và tôi thấy nội dung được xuất ra khi thực hiện cuộn tròn thành 172.20.0.1:8000:
25 tháng 3 09:01:38.570 x kernel: TRACE: raw:PREROUTING:policy:4 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00: 08:00 SRC=172.20.0.1 DST=172.20.120.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=44467 DF PROTO=TCP SPT=40096 DPT=30280 SEQ=191700158 ACK=0 WINDOW=43690 RES=0x00 SYN URGP=0 LỰA CHỌN (0204FFD70402080A20C6B10D0000000001030307)
Ngày 25 tháng 3 09:01:38.570 x kernel: TRACE: mangle:PREROUTING:rule:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00: 08:00 SRC=172.20.0.1 DST=172.20.120.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=44467 DF PROTO=TCP SPT=40096 DPT=30280 SEQ=191700158 ACK=0 WINDOW=43690 RES=0x00 SYN URGP=0 LỰA CHỌN (0204FFD70402080A20C6B10D0000000001030307)
Ngày 25 tháng 3 09:01:38.570 x kernel: TRACE: mangle:cali-PREROUTING:rule:3 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00: 00:08:00 SRC=172.20.0.1 DST=172.20.120.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=44467 DF PROTO=TCP SPT=40096 DPT=30280 SEQ=191700158 ACK=0 WINDOW=43690 RES =0x00 SYN URGP=0 CHỌN (0204FFD70402080A20C6B10D0000000001030307)
Ngày 25 tháng 3 09:01:38.570 x kernel: TRACE: mangle:cali-from-host-endpoint:return:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00: 00:00:00:08:00 SRC=172.20.0.1 DST=172.20.120.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=44467 DF PROTO=TCP SPT=40096 DPT=30280 SEQ=191700158 ACK=0 WINDOW=43690 RES=0x00 SYN URGP=0 OPT (0204FFD70402080A20C6B10D0000000001030307)
Và khi tôi gửi yêu cầu trực tiếp đến 172.20.120.1:30280 nó hoạt động và tôi nhận được phản hồi thành công, vì vậy tôi không thể hiểu tại sao quy tắc DNAT không hoạt động.
Tôi cũng đã thử mở tường lửa để CHẤP NHẬN tất cả nhưng cũng không được.
iptables -P CHẤP NHẬN ĐẦU VÀO
iptables -P CHẤP NHẬN ĐẦU RA
Tôi cũng có thể thấy kích thước gói quy tắc OUTPUT tăng lên khi thực hiện yêu cầu cuộn tròn thành 172.20.0.1:8000 vì vậy tôi biết quy tắc đó đang bị ảnh hưởng.
Có ai biết tại sao tôi không thể cong 172.20.0.1:8000 và nhận được phản hồi thành công nhưng khi cuộn tròn 172.20.120.1:30280 trực tiếp nó hoạt động tốt?
