iptables -j REDIRECT는 *실제로* 패킷 헤더에 어떤 작업을 수행합니까?

호기심에서 투명한 TOR 프록시에 대한 몇 가지 튜토리얼을 읽고 있습니다. 이는 네트워크 관점에서 볼 때 매우 흥미로운 주제이기 때문입니다. tun/ 인터페이스 만 사용하는 VPN 게이트웨이와 달리 tapTOR 프록시는 단일 포트를 사용합니다. 모든 튜토리얼에서는 다음과 같은 마법의 라인을 반복합니다.

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

그 중에는 TOR 포트인 eth0입력(LAN) 인터페이스가 있습니다 . 9040문제는 왜 그런 일이 네트워크 관점에서 의미가 있는지 전혀 모른다는 것입니다.

redirect/ 체인에 대한 나의 이해 dst-nat와 그것이 물리적 라우터에서 어떻게 작동하는지에 따르면, 체인은 다음과 dst-nat같아야 합니다 .dst-portdst-addr 앞으로라우팅 결정을 내리고 다른 것으로 변경합니다. 예를 들어:

• 앞으로 dst-nat:192.168.1.2:46364 -> 88.88.88.88:80
• 뒤쪽에 dst-nat:192.168.1.2:46364 -> 99.99.99.99:8080

이는 99.99.99.99:8080IP 패킷 흐름 채널의 추가 체인(예: filter테이블)에서 볼 수 있는 내용이며, 이제부터 패킷이 장치를 떠날 때의 모습입니다.

이제 인터넷(이 stackexchange를 포함하여)의 많은 사람들은 이것이 redirect기본적으로 인터페이스에 로컬 주소를 설정하는 것과 동일하다고 주장합니다. 이를 고려하면 규칙은 다음과 같습니다.dst-natdst-addr

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

분명히 말이되지 않습니다. 이것이 작동하는 방식이라면 TOR는모두패킷의 목적지는 입니다 127.0.0.1:9040. 애플리케이션이 패킷을 가져오고 어떤 방식으로든 이에 응답하는 일반적인 애플리케이션(예: 웹 서버)의 경우 이는 완벽하게 이해됩니다. 왜냐하면 결국 이러한 서버 프로세스는 어쨌든 패킷의 최종 대상이므로 대상은 주소는 localhost인데 괜찮습니다. 하지만 TOR 라우터는 좋은 라우터이므로 패킷의 원래 목적지를 알아야 합니다. 내가 뭐 놓친 거 없니? DNAT로컬 애플리케이션이 수신하는 내용에 영향을 미치지 않습니까 ? 아니면 REDIRECT명령어의 특정 동작인가요?