Linux 방화벽(firewalld)부터 TCP 3-Way Handshake까지

# 처음 들었던 의문

구성은 대략 이랬다.

• 2번 서버에 WAS(JEUS)가 기동되어 있고
• 해당 WAS 위에 웹 애플리케이션이 올라가 있다
• 이 웹 애플리케이션은
  내부적으로 같은 서버에 설치된 특정 솔루션의 화면에 접근하기 위한 웹 페이지다
• 이 솔루션은 별도의 TCP 포트(10255)를 사용해 통신한다

여기서 자연스럽게 이런 의문이 들었다.

 

1번 서버에서 2번 서버의 JEUS 포트만 허용된 상태라면, 그 JEUS 위에 올라간 웹 페이지를 통해 2번 서버 내부 솔루션(10255 포트)에 정상적으로 접근할 수 있을까?

 

2번 서버에는 WAS와 해당 솔루션이 함께 구성되어 있었기 때문에, 서버 내부 통신이라는 점에서 문제없이 동작할 것이라고 생각했다. 다만 실제 운영 환경에서는 내부 방화벽 정책이나 네트워크 구성 등 다른 요소들로 인해 실제로 어떤 통신이 오가는지 확인해보기로 했다.

 

 

# 테스트 환경 구성

1번 서버 IP: 192.168.0.1
2번 서버 IP: 192.168.43.100
JEUS 포트: 8081
내부 솔루션 포트: 10255

 

 

가장 먼저 방화벽 설정부터 확인했다.

# 방화벽 설정 확인

 

IP 에 대해 서비스 포트 허용

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address=192.168.0.1 port port="8081" protocol="tcp" accept'

 

 

방화벽 적용

firewall-cmd --reload

 

 

1. 1번 로컬에서 WAS 띄워서 2번 솔루션에 접속

2. 1번에서 2번 WAS 띄워서 2번 솔루션에 접속

 

 

# tcpdump로 확인한 패킷 흐름

tcpdump -nn -i any port 10255

실시간으로 출발지 IP / 목적지 IP 포트 / SYN 들어오는지 확인할 수 있는 리눅스 명령어이다. 물론 실제 운영 환경에서는 보안 정책상 tcpdump 권한이 제한되어 있는 경우가 많아 항상 사용할 순 없다..

 

#tcpdump로 확인한 패킷 흐름
IP 192.168.0.1.13345 > 192.168.43.100.10255: Flags [S]
IP 192.168.43.100.33001 > 192.168.43.100.10255: Flags [S]
IP 192.168.43.100.10255 > 192.168.43.100.33001: Flags [S.]
IP 192.168.43.100.33001 > 192.168.43.100.10255: Flags [.]

• Flags [S]: SYN 연결 시작
• Flags [S.]: SYN-ACK - 서버 응답
• Flags [.]: ACK - 클라이언트가 ACK 반환 / 연결 성립

tcpdump 결과를 보면, 1번 서버에서 10255 포트로는 SYN 패킷만 유입되고 응답이 없었지만, 2번 서버 내부에서 발생한 통신은 정상적으로 3-Way Handshake가 이루어지고 있었다.

즉 외부 통신과 내부 통신의 동작이 명확히 달랐다.