Я пытаюсь сделать локальный запрос к кластеру kubernetes, размещенному на моем сервере, NodePort кластера прослушивает следующий адрес 172.20.120.1:30280. Внешний клиент в производстве должен делать запросы к 172.20.0.1:8000 (это не может измениться), поэтому я пытаюсь добавить правило DNAT для передачи трафика из:
172.20.0.1:8000 -> 172.20.120.1:30280 (порт узла k8s)
Я добавил следующее правило DNAT PREROUTING:
Цепочка PREROUTING (политика ACCEPT 2614 пакетов, 170К байт)
num pkts bytes target prot opt in out source target
...
26 27462 1648K DNAT TCP -- * * 0.0.0.0/0 172.20.0.1 TCP dpt:8000 to:172.20.120.1:30280
и следующее правило OUTPUT:
# iptables -v -L ВЫВОД -n --номера строк | голова -10
Цепочка OUTPUT (политика ACCEPT 0 пакетов, 0 байт)
num pkts bytes target prot opt in out source target
...
4 943 156K tcp -- * * 0.0.0.0/0 172.20.120.1 tcp dpt:30280
Я могу сделать запрос на завивку 172.20.120.1:30280 напрямую и получить успешный ответ. Однако, когда я делаю запрос на завивку 172.20.0.1:8000 он просто висит со следующим сообщением:
# curl -vvvk https://172.20.0.1:8000/v1/my-api
* О подключении() к порту 172.20.0.1 8000 (#0)
* Попытка 172.20.0.1...
* Подключено к порту 172.20.0.1 (172.20.0.1) 8000 (#0)
* Инициализация NSS с помощью certpath: sql:/etc/pki/nssdb
И тогда это в конечном счете истекает.
Мой tcpdump показывает, что трафик перенаправляется на этот правильный IP-адрес при запуске запроса curl на 172.20.0.1:8000:
# tcpdump -nnvvv -i любой src 172.20.0.1 и dst 172.20.120.1
tcpdump: прослушивание на любом, ссылка типа LINUX_SLL (линукс сваренный), размер захвата 262144 байт
08:47:07.108364 IP (tos 0x0, ttl 64, id 27172, смещение 0, флаги [DF], proto TCP (6), длина 60)
172.20.0.1.52910 > 172.20.120.1.30280: Флаги [S], cksum 0xd85d (неверно -> 0x84e2), seq 1825443523, win 43690, параметры [mss 65495, sackOK, TS val 549020903 ecr 0,nop,wscale] , длина 0
08:47:07.108771 IP (tos 0x0, ttl 64, id 27173, смещение 0, флаги [DF], proto TCP (6), длина 52)
172.20.0.1.52910 > 172.20.120.1.30280: Флаги [.], cksum 0xd855 (неправильно -> 0x3029), seq 1825443524, ack 3881482736, win 342, options [nop,nop,TS val 5490209094], длина 0ecr 904 54
08:47:07.206994 IP (tos 0x0, ttl 64, id 27174, смещение 0, флаги [DF], proto TCP (6), длина 229)
...
Кроме того, я добавил TRACE в правила iptable, и я вижу вывод данных при создании завитка для 172.20.0.1:8000:
25 марта 09:01:38.570 x ядро: 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=191700158 ACK=0 WINDOW=43690 RES=0x00 SYN URGP=0 ОПТ (0204FFD70402080A20C6B10D0000000001030307)
25 марта 09:01:38.570 x ядро: 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=191700158 ACK=0 WINDOW=43690 RES=0x00 SYN URGP=0 ОПТ (0204FFD70402080A20C6B10D0000000001030307)
25 марта 09:01:38.570 x ядро: 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=191700158 ACK=0 WINDOW=43690 RES =0x00 СИН URGP=0 ОПТ (0204FFD70402080A20C6B10D0000000001030307)
25 марта 09:01:38.570 x ядро: 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)
И когда я делаю запрос напрямую 172.20.120.1:30280 это работает, и я получаю успешный ответ, поэтому я просто не могу понять, почему правило DNAT не работает.
Я также попытался открыть брандмауэр, чтобы ПРИНЯТЬ все, но это тоже не сработало.
iptables -P ВВОД ПРИНЯТЬ
iptables -P ВЫВОД ПРИНЯТЬ
Я также вижу увеличение размера пакета правила OUTPUT при выполнении запроса curl на 172.20.0.1:8000 так что я знаю, что это правило получает удар.
Кто-нибудь знает, почему я не могу свернуть 172.20.0.1:8000 и получить успешный ответ, но когда curl 172.20.120.1:30280 напрямую работает нормально?
