나는 MASQUERADE 대상이 응답 방향의 패킷과 일치하지 않는다는 것을 관찰했습니다(netfilter conntrack에 관한 한).
모든 온체인 정책을 수락하는 것 외에 다른 규칙이 없는 간단한 규칙이 있는데 -t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE
다음과 같습니다.
사례 1) 10.a/16 네트워크의 연결 초기화 시도에서 나온 SYN 패킷은 NAT를 통과하지만(정상임)
사례 2) 10.a/16 네트워크에서 다시 오는 SYN/ACK 패킷(10.b/16에서 오는 SYN에 대한 응답, 즉 이 경우 개시자는 10.b/16임)은 변환되지 않지만 src 주소는 다음과 같습니다. 그대로 두고 간단한 라우팅을 수행합니다.
이것이 예상된 동작인지 아니면 뭔가 빠졌는지 잘 모르겠습니다. 내 말은, 그것이 다른 방식으로 행동하는 것을 원하지 않는다는 것입니다. 모든 것이 괜찮아 보입니다. 그러나 문서에서는 이것이 MASQUERADE 대상의 공장 기본 동작임을 확인하지 않습니다.
이것을 확인해주실 수 있나요? 감사해요.
답변1
TCP 연결의 ID는 다음 네 가지로 정의됩니다.
- 엔드포인트 A의 IP 주소
- 엔드포인트 B의 IP 주소
- 엔드포인트 A의 포트 번호
- 엔드포인트 B의 포트 번호
TCP 프로토콜 표준은 다음과 같이 규정합니다.어느이 네 가지 사항이 변경되면 패킷을 동일한 연결의 일부로 간주하면 안 됩니다. 따라서 초기 SYN이 NAT 처리되지 않은 경우 NAT 규칙을 SYN/ACK 패킷에 적용하는 것은 의미가 없습니다. 처음부터 끝까지 전체 연결에 동일한 유형의 NAT 매핑을 적용해야 합니다. 그렇지 않으면 연결에서 NAT 매핑을 추가하거나 변경하려고 하면 TCP 연결이 실패하게 됩니다. 이는 TCP 프로토콜의 기본 사실이며 Linux iptables/netfilter 코드는 이를 염두에 두고 설계되었습니다.
귀하의 경우 2)에서는 SYN/ACK 앞에 10.b/16의 SYN이 옵니다. 이 SYN의 소스는 10.b/16이므로 MASQUERADE 규칙과 일치하지 않으며 있는 그대로 주소를 사용하여 라우팅됩니다. 그 다음에,SYN/ACK를 10.a/16에서 다시 10.b/16으로 변환하는 경우, 원본 SYN의 발신자더 이상 응답으로 인식되지 않습니다.소스 IP + 대상 IP + 소스 포트 + 대상 포트 조합이 유효한 응답에 대해 예상되는 것과 다르기 때문에 자체 SYN에 연결합니다.
기본적으로 10.b/16에서 연결을 시작한 시스템의 TCP 프로토콜 드라이버는 "으아. 10.a.connection.destination
응답이 없습니다."라고 생각합니다. 그리고 명백히 가짜 SYN/ACK가 저를 괴롭혔습니다. 시간이 있으면 10.b.NAT.system
연결하려고 했는데 , 그가 자신의 실수를 깨닫고 나를 괴롭히지 않기를 바라면서 10.a.connection.destination
RST를 한두 번 보낼 것입니다 .”10.b.NAT.system
답변2
MASQUERADE는 나가는 인터페이스 소스가 있는 SNAT(소스 NAT)입니다( man iptables-extensions
.
연결 시도(초기 SYN)가 NAT 처리되고, 연결이 커널("conntrack")에서 추적되며, 연결의 모든 패킷이 적절한 방향으로 NAT 처리됩니다.
그렇습니다. 들어오는 SYN에 대한 나가는 SYN/ACK 응답은 SNAT에 의해 NAT 처리되지 않습니다. 들어오는 SYN을 NAT로 연결하려면 SNAT가 아닌 DNAT가 필요합니다. 이는 또한 SYN/ACK 응답을 NAT합니다.
답변3
이는 패킷이 반대 방향으로 이동할 때 소스가 10.b/24이고 대상이 10.a/24이므로 규칙에 따라 처리되지 않기 때문에 발생합니다. MASQUERADE를 실행하려면 두 가지 규칙을 추가해야 합니다.
-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE
-t nat -A POSTROUTING -s 10.b.0.0/16 -d 10.a.0.0/16 -j MASQUERADE