연결 추적에 관한 Iptables 문서를 읽고 있습니다.여기제가 강조한 다음 부분을 계산하는 데 문제가 있습니다.
tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
dport=32775 [ASSURED] use=2
이 예에는 특정 연결의 상태를 알기 위해 conntrack 모듈에서 유지 관리하는 모든 정보가 포함되어 있습니다. 먼저 프로토콜이 있습니다. 이 경우에는 tcp입니다. 다음은 일반 십진수 인코딩에서도 동일한 값입니다. [...]마지막으로 반환된 패킷에서 예상되는 내용을 살펴봅니다. 이 정보에는 소스 IP 주소와 대상 IP 주소가 자세히 설명되어 있습니다(패킷이 다시 우리에게 전달되므로 둘 다 반대입니다). 연결의 소스 및 대상 포트에도 동일하게 적용됩니다.
예상되는 IP 및 포트(그냥 반대인 경우)를 추적하는 것이 왜 유용한지 알 수 없습니다. 패킷이 도착하면 IP와 포트 쌍만을 사용하여 조회를 수행하며, 찾을 수 없는 경우에는 동일한 필드를 사용하여 조회를 수행할 수 있습니다. 이 정보를 유지하는 것이 일종의 최적화인가요? 아니면 일부 사용 사례가 누락된 것인가요? 이것이 무언가를 달성할 수 있는 유일한 방법인가요?
감사해요
답변1
현재 및 예상 상태를 추적하는 데 유용합니다. 의도한 IP와 포트가 단순히 역순으로 바뀌지 않을 때 가장 유용합니다. 예를 들어 NAT를 사용하거나 역방향이 정확히 동일하지 않은 경우 이런 일이 발생할 수 있습니다. 또한 관련된 경우(예: TCP의 경우) 상태 전환이 존중되는지 확인합니다. 몇 가지 예:
192.0.2.2에서 간단한 핑을 보낸 후 응답은 초기 유형 8(에코 요청) 대신 ICMP 유형 0(에코 응답)을 가질 것으로 예상됩니다.
icmp 1 12 src=192.0.2.2 dst=8.8.8.8 type=8 code=0 id=26387 src=8.8.8.8 dst=192.0.2.2 type=0 code=0 id=26387 mark=0 use=1
conntrack -E공용 IP 198.51.100.32의 NAT 라우터 뒤에 있는 호스트 10.1.2.3에서 FTP 서버 203.0.113.47로의 활성(수동 아님) FTP 세션(추적을 통해 ). 응답에는 라우터의 IP가 필요하며 NAT가 적용된(인터넷을 통해 라우팅할 수 없는) FTP 클라이언트의 IP는 필요하지 않습니다. 원하는 생성은 SNAT(또는 MASQUERADE) 규칙에 의해 변경됩니다.
[NEW] tcp 6 120 SYN_SENT src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 [UNREPLIED] src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 helper=ftp
[UPDATE] tcp 6 60 SYN_RECV src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 helper=ftp
[UPDATE] tcp 6 432000 ESTABLISHED src=10.1.2.3 dst=203.0.113.47 sport=47800 dport=21 src=203.0.113.47 dst=198.51.100.32 sport=21 dport=47800 [ASSURED] helper=ftp
ls예상 항목이 클라이언트의 ftp PORT 명령에서 계산된 대상과 일치하고 이전 conntrack 항목(nat 포함)이 트래픽 통과를 허용하기 위해 ftp 도우미에 의해 예상 테이블에 추가된 후(예를 들어추가 도우미 처리 전에 방화벽에서 관련 규칙을 사용하십시오. 이것은 거기에서 읽을 수 있습니다(그러나 일치하는 즉시 연결이 사라집니다.이것연결이 표시되므로 방화벽 지연이 없으면 실제로 볼 수 없습니다.)
# cat /proc/net/nf_conntrack_expect
295 l3proto = 2 proto=6 src=203.0.113.47 dst=198.51.100.32 sport=0 dport=41603 ftp
그리고 어시스턴트(여기서는 DNATed, 여전히 도움을 받기 위해 이전 conntrack 항목을 사용)에 의한 추가 변경으로 인해 다음과 같은 새로운 추적 연결이 생성됩니다.
[NEW] tcp 6 120 SYN_SENT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 [UNREPLIED] src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20
[UPDATE] tcp 6 60 SYN_RECV src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20
[UPDATE] tcp 6 432000 ESTABLISHED src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[UPDATE] tcp 6 120 FIN_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[UPDATE] tcp 6 60 CLOSE_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[UPDATE] tcp 6 30 LAST_ACK src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[UPDATE] tcp 6 120 TIME_WAIT src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
[DESTROY] tcp 6 src=203.0.113.47 dst=198.51.100.32 sport=20 dport=41603 src=10.1.2.3 dst=203.0.113.47 sport=41603 dport=20 [ASSURED]
이러한 예상 항목은 모두 트래픽을 추적하는 데 사용됩니다(conntrack). 예를 들어 추적되지 않는 항목을 제거하여 상태 저장 방화벽을 보유하는 것은 쉽습니다(초기 ICMP 에코 핑을 수행하지 않은 경우 ICMP 에코 응답이 통과하지 않도록 하십시오). 이전에 동일한 ID를 사용) 및 IP/포트 변환 방법을 기억하십시오(nat를 사용하는 경우).