iptables REDIRECT는 인터페이스와 IP 주소 일치를 결합합니다.

Tor를 성공적으로 설정했습니다투명 프록시iptables를 사용하십시오(즉, 나가는 모든 트래픽은 애플리케이션이 알지 못하는 사이에 Tor를 통해 전송됩니다). 그렇게 하면서 나는 이상한 문제와 마찬가지로 이상한 수정 사항(해결 방법?)을 발견했습니다.

내 규칙은 다음과 같습니다. 사용자 정의 체인이나 기타 규칙이 없으며 모든 정책이 허용됩니다.

-t nat -A OUTPUT -o lo -j RETURN
-t nat -A OUTPUT -p tcp -m owner --uid-owner tor -j RETURN
-t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports 54
-t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 55

-A INPUT -j ACCEPT

-A OUTPUT -o lo -j ACCEPT # Rule A
-A OUTPUT -d 127.0.0.1 -j ACCEPT # Rule B
-A OUTPUT -p tcp -m owner --uid-owner tor -j ACCEPT
-A OUTPUT -j REJECT # Rule C

다시 말해서:

• localhost에서 들어오고 나가는 모든 트래픽은 변경되지 않습니다.
• Tor에서 생성된 모든 트래픽은 영향을 받지 않습니다.
• 나가는 모든 TCP 연결은 Tor(투명 프록시 포트 54)를 통해 전송됩니다.
• 나가는 모든 DNS 쿼리는 Tor(포트 55의 DNS)에 의해 해결됩니다.
• 누출을 방지하기 위해 다른 모든 나가는 트래픽은 벽돌로 머리 위로 부딪혀 도랑에 던져졌습니다.

(이 설정에는 LAN 연결에 응답하지 않는 등 몇 가지 문제가 있지만 이는 현재 문제와 관련이 없습니다.)

규칙 B가 존재하지 않으면 모든 나가는 연결은 규칙 C에 의해 즉시 거부됩니다. 거부 유형(예: --reject-with icmp-proto-unreachable)을 변경하면 다른 오류가 발생하기 때문에 규칙 C에 의해 거부된다는 것을 알고 있습니다. 규칙 B가 없는 오류 메시지 예:

# With Rule C --reject-with icmp-port-unreachable, the default:
$ curl 213.155.151.153 # (google.com; DNS also doesn't work)
curl: (7) Failed connect to 213.155.151.153:80; Connection refused

# With Rule C --reject-with icmp-proto-unreachable:
$ curl 213.155.151.153
curl: (7) Failed connect to 213.155.151.153:80; Protocol not available

규칙 B를 사용하면 연결이 제대로 작동합니다.

iptables에 대한 내 이해에 따르면 나가는 TCP 연결이 설정되면 OUTPUT 체인의 세 번째 규칙이 nat패킷의 대상을 127.0.0.1:54로 다시 씁니다. 그런 다음 패킷은 OUTPUT 체인으로 filter들어가고~해야 한다나가는 인터페이스가 이제 루프백 인터페이스이기 때문에 규칙 A와 일치합니다. 그러나 그것은아니요규칙 A가 일치하고 규칙 B(일치하는)가 존재하지 않으면 패킷은 골목으로 끌려가 규칙 C에 의해 강탈됩니다.

규칙 A와 규칙 B가 동일하지 않은 이유는 무엇입니까? 이 경우 루프백 인터페이스 일치와 루프백 주소 일치는 어떻게 다릅니까?