iptables에 REDIRECT 규칙을 추가한 후 다른 리디렉션 포트를 표시하는 Tcpdump

Question

명확하게 말하면 OP의 테스트는 원격 시스템이 아닌 시스템 192.168.1.100에서 자체적으로 수행되며 이것이 문제의 원인입니다. 이 경우에는 일치하는 NAT 규칙이 없기 때문에 포트가 변경되지 않았지만 원격 시스템에서 수행했다면 일치했을 것입니다.

아래 회로도는 패킷에서 작업 순서가 수행되는 방식을 보여줍니다.

그 이유는 Linux에서 NAT가 작동하는 방식입니다.iptablesnat새로운 conntrack 흐름(따라서 NEW 상태임)의 첫 번째 패킷에 대해서만 테이블 의 패킷을 봅니다 .

이 규칙은 원격 시스템에서 잘 작동합니다. 이 경우 표시되는 첫 번째 패킷은 수신 패킷입니다.

to port 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): to port 30000
--> routing decision --> ... --> local process receiving on port 30000

동일한 흐름의 모든 후속 패킷에는 conntrack이 포트 변경(또는 응답을 위한 포트 전환)을 직접 처리하고 테이블의 iptables 규칙을 건너뜁니다 nat(회로도: 연결 nat에만 참조된 테이블에 기록됨 NEW). 따라서 (응답 패킷 부분을 건너뛰고) 다음 수신 패킷은 대신 다음을 수행합니다.

to port 8000 --> AF_PACKET (tcpdump) --> conntrack: to port 30000
--> routing decision --> ... --> local process receiving on port 30000

시스템 자체에 대한 테스트의 경우 첫 번째 패킷은 들어오는 패킷이 아니라 나가는 패킷입니다. 대신 나가는 lo인터페이스를 사용하면 이런 일이 발생합니다.

local process client curl --> routing decision --> conntrack --> nat/OUTPUT (no rule here)
--> reroute check --> AF_PACKET (tcpdump) --> to port 8000

이제 이 패킷은 인터페이스에서 루프백되어 lo더 이상 연결의 첫 번째 패킷이 아닌 패킷으로 다시 나타나므로 위와 같이 두 번째 경우를 따릅니다. conntrack 단독으로 NAT를 처리하고 호출하지 않습니다 nat/PREROUTING. NAT를 수행하기 전 단계에서 지시되지 않은 경우를 제외하고는 다음과 같습니다.

to port 8000 --> AF_PACKET (tcpdump) --> conntrack
--> routing decision --> ... -->nolocal process receiving on port8000

포트 8000에서 수신 대기 중인 항목이 없으므로 OS는 TCP RST를 다시 보냅니다.

이것이 로컬 시스템에서 작동하려면 체인 REDIRECT에 규칙도 추가되어야 합니다 nat/OUTPUT.

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

추가 참고사항

사례가 원격 사용을 위한 것이라면 로컬 시스템에서 테스트하지 마세요. 테스트에서 통과하는 규칙은 동일하지 않습니다. 이는 테스트가 현실을 반영하지 못하게 만듭니다.

다른 시스템을 사용할 수 없는 경우를 대비해 네트워크 네임스페이스를 사용하여 포켓 원격 시스템을 만드세요. OP의 nat/PREROUTING규칙 만 있고 수행하는 시스템에서 작동해야 하는 예 curl http://192.168.1.100/(DNS가 필요하지 않음):
```
ip netns add remotesystem
ip link add name vethremote up type veth peer netns remotesystem name eth0
ip address add 192.0.2.1/24 dev vethremote
ip -n remotesystem address add 192.0.2.2/24 dev eth0
ip -n remotesystem link set eth0 up
ip -n remotesystem route add 192.168.1.100 via 192.0.2.1
ip netns exec remotesystem curl http://192.168.1.100:8000/
```
tcpdump및 NAT

tcpdumpAF_PACKET위 회로도의 단계 에서 발생합니다 . 즉, 수신의 경우 매우 초기이고 송신의 경우 매우 늦습니다. 이는 원격 시스템의 경우 작동 중이더라도 포트 30000을 캡처하지 않음을 의미합니다. 로컬 시스템의 경우 nat/OUTPUT규칙이 추가되면 포트 30000을 캡처합니다.

NAT를 수행할 때 표시되는 주소/포트를 맹목적으로 신뢰하지 마십시오 tcpdump. 상황과 캡처가 발생하는 위치에 따라 다릅니다.

Answer 1