Încerc să fac o solicitare locală către cluster-ul kubernetes care este găzduit pe serverul meu, NodePort-ul cluster-ului ascultă la următoarea adresă 172.20.120.1:30280. Clientii externi din productie trebuie sa faca cereri catre 172.20.0.1:8000 (acest lucru nu se poate schimba), așa că încerc să adaug o regulă DNAT pentru a controla traficul de la:
172.20.0.1:8000 -> 172.20.120.1:30280 (k8s NodePort)
Am adăugat următoarea regulă de PREROUTING DNAT:
PRERUUTARE în lanț (politica ACCEPTĂ 2614 pachete, 170K octeți)
num pkts octeți target prot opt in out sursă destinație
...
26 27462 1648K DNAT tcp -- * * 0.0.0.0/0 172.20.0.1 tcp dpt:8000 la:172.20.120.1:30280
și următoarea regulă OUTPUT:
# iptables -v -L OUTPUT -n --line-numbers | cap -10
Ieșire în lanț (politica ACCEPT 0 pachete, 0 octeți)
num pkts octeți target prot opt in out sursă destinație
...
4 943 156K tcp -- * * 0.0.0.0/0 172.20.120.1 tcp dpt:30280
Pot să fac cerere curl către 172.20.120.1:30280 direct și obțineți un răspuns de succes înapoi. Cu toate acestea, când fac o cerere de curl la 172.20.0.1:8000 se blochează doar cu următorul mesaj:
# curl -vvvk https://172.20.0.1:8000/v1/my-api
* Urmează să se conecteze() la portul 172.20.0.1 8000 (#0)
* Încercați 172.20.0.1...
* Conectat la 172.20.0.1 (172.20.0.1) portul 8000 (#0)
* Inițializarea NSS cu certpath: sql:/etc/pki/nssdb
Și apoi în cele din urmă expiră.
Tcpdump-ul meu arată că traficul este redirecționat către acel IP corect atunci când declanșează cererea curl la 172.20.0.1:8000:
# tcpdump -nnvvv -i orice src 172.20.0.1 și dst 172.20.120.1
tcpdump: ascultare pe orice, LINUX_SLL de tip link (Linux cooked), dimensiunea capturii 262144 octeți
08:47:07.108364 IP (to 0x0, ttl 64, id 27172, offset 0, flags [DF], proto TCP (6), lungime 60)
172.20.0.1.52910 > 172.20.120.1.30280: steaguri [S], cksum 0xd85d (incorectă -> 0x84e2), seq 1825443523, win 43690, opțiuni [msTS] ecs909040, opțiuni [msts] ecs90909090, 900000000001 , lungime 0
08:47:07.108771 IP (to 0x0, ttl 64, id 27173, offset 0, flags [DF], proto TCP (6), lungime 52)
172.20.0.1.52910 > 172.20.120.1.30280: steaguri [.], cksum 0xd855 (incorect -> 0x3029), seq 1825443524, ack 3881482736, opțiunile 3881482736, TS 940 302736, TS 940 val 340, opțiuni 940 500 340
08:47:07.206994 IP (to 0x0, ttl 64, id 27174, offset 0, flags [DF], proto TCP (6), lungime 229)
...
De asemenea, am adăugat TRACE la regulile iptable și văd lucruri afișate când fac curl la 172.20.0.1:8000:
Mar 25 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: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=19581704=1950INDACK=060170044467 DF SYN URGP=0 OPT (0204FFD70402080A20C6B10D0000000001030307)
Mar 25 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: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=19581704=1950INDACK=060170044467 DF SYN URGP=0 OPT (0204FFD70402080A20C6B10D0000000001030307)
Mar 25 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: 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=19804001980400015000001504001 =0x00 SYN URGP=0 OPT (0204FFD70402080A20C6B10D0000000001030307)
Mar 25 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=30298ACK=302981 SEQ=302981 WINDOW=43690 RES=0x00 SYN URGP=0 OPT (0204FFD70402080A20C6B10D0000000001030307)
Și când fac o cerere direct către 172.20.120.1:30280 funcționează și primesc un răspuns de succes înapoi, așa că nu pot să-mi înțeleg de ce regula DNAT nu funcționează.
De asemenea, am încercat să deschid firewall-ul pentru a ACCEPT pe toate, dar nici asta nu a funcționat.
iptables -P INTRARE ACCEPT
iptables -P ACCEPT IEȘIRE
De asemenea, pot vedea mărimea pachetului de reguli de IEȘIRE când fac cererea de curl către 172.20.0.1:8000 așa că știu că regula a fost lovită.
Știe cineva de ce nu mă pot ondula 172.20.0.1:8000 și obțineți un răspuns de succes înapoi, dar când curl 172.20.120.1:30280 direct merge bine?
