Troubleshooting - ERR_CONNECTION_RESET 해결 기록

개발계에 신규 Application 배포 중 로컬에서는 정상적으로 접근이 되는데, 외부에서는 정상적으로 접근이 되지 않는 현상 (ERR_CONNECTION_RESET)이 발생되어 이를 해결한 내용을 기록해놓고자 한다. 트래픽 흐름은 LB → WAF → VM 순서로 트래픽이 흐르게 된다.

1. ERR_CONNECTION_RESET?

이 외국계 블로그에 따르면 ERR_CONNECTION_RESET은 Browser가 정상적인 패킷 대신 FIN Packet을 받아서 발생하는 것이라고 한다. 구글에 검색해보면 일반적으로 브라우저단에서 처리하는 해결방법이 나오는데, 이번 사례는 브라우저단에서 해결할 수 있는 내용이 아닌 것 같아 관련된 내용은 생략한다.

2. 서버에서는?

서버에 와이어샤크를 설치하고 특정 TCP Stream을 추적해보았다. 

보면, 위와 같이 3Way HandShake가 이루어지자마자 WAF 장비 (.36)에서 [FIN, ACK]를 서버 (.7)로 보내는 것을 확인할 수 있다. 커넥션이 맺어지자마자 (시간상으로는 완전히 똑같은 시간대에) 클라이언트에서 바로 이를 종료하여 서버에서는 이를 비정상으로 인지하고 RST시키는 것으로 추정이 된다.

(※ 그러나 뒤에서 언급하겠지만 이 추정은 틀렸을 것으로 보인다.)

3. 원인은?

결국 서버는 원인에서 제외하고, 클라이언트도 로컬에서는 정상적으로 수행되니 이를 제외하면 두 구간 (LB, WAF)이 이에 해당한다. 설정을 확인하던 중 WAF 장비에 "Source Address Translation (SNATs)" 이라는 설정이 기존 설정들과 다르게 None으로 설정되어 있어 이를 Auto Map으로 변경해주었다. 

설정 변경 이후 아래와 같이 정상적으로 TLS Handshake를 하고 접속이 되는 것을 확인하였다. 

4. 그러나..

그런데 눈치챘을 수도 있겠지만, Client의 Source 주소를 NAT시킨 것(해결책)에 대한 원인 추정은 틀렸을 것으로 보인다. 이 부분은 WAF 장비에서 Server로 Healthcheck하는 트래픽이 발생한 것으로 보인다. 아마 Source NAT가 안된 트래픽이 흘러갔으므로 요청에 대해 정상적으로 답변주지 못했을 가능성이 크다. 일단 해결되서 다행이지만.. 원인 파악에 너무 성급해서 잘못된 TCP Stream을 추적했던 것 같다. 아마 좀 더 테스트를 했으면 원인 파악을 보다 빨리 할 수 있었을 것 같다.