슬랙이 연결을 끊었다.
슬랙 웹훅 알림 메시지 유실로인한 문제를 tcpdump를 활용하여 디버깅했던 내역을 정리
1. 증상
신규 운영환경 모니터링 시스템 구축 중 슬랙 메시지가 간헐적으로 오지않는것을 확인
- 서버에서 Slack webhook 메시지 전송 시 간헐적 실패
- 상대편이 연결을 끊었다는 로그 확인
- 약 10건 중 1~2건 실패, 랜덤하게 발생
- 같은 webhook URL을 쓰는 다른 서버에서는 문제 없음
2. 에러 식별
- curl 응답코드 000 (HTTP 응답 자체를 못 받음)
- 에러: curl: (35) Recv failure: 상대편이 연결을 끊음
- rate limit(429)이 아닌 네트워크/TLS 레벨 문제 확인
3. tcpdump 패킷 분석
- hooks.slack.com은 DNS 라운드로빈으로 매번 다른 IP 반환
- 대부분의 IP는 정상 통신
- DNS가 넘겨준 특정 IP(35.73.126.78)에 걸리면 TCP 핸드쉐이크 성공 후 -> TLS Client Hello 전송 직후 2ms 만에 RST수신
- 09:37:41.120441 → [P.] PUSH: Client Hello 전송 (seq 1:518, 517바이트)
- 09:37:41.122140 → [R] RST: 2ms 만에 강제 끊김.. (몇홉까지못하고 반송당한것이 확실..)
- 35.73.126.78 <- 문제의 IP....
4. 다른 서버 간 비교
- 다른 정상서버 → 35.73.126.78: 성공
- 해당 문제서버 → 35.73.126.78: 실패
- curl/OpenSSL 버전 동일, iptables 필터링 없음
- Slack 노드 문제가 아닌 우리측 문제서버의 고유 문제 확정
5. SNI 기반 필터링 확인
- SNI없이 단순 IP 접속시와 도메인명을 통한 SNI 접속시 문제 발생 확인
- SNI 없이 IP로 직접 접속: TLS 성공
- SNI에 hooks.slack.com 포함: RST로 실패
- TLS Client Hello의 SNI 필드를 검사하는 DPI 장비가 경로에 존재 확인
- 고객사 방화벽 장비 axgate 40d
6. 근본 원인 추측
- 문제 서버 → 13.201.10.254 게이트웨이 경로에 있는 방화벽장비가 SNI기반으로 hooks.slack.com + 특정 목적지 IP 조합의 트래픽을 차단하고 있음
- SNI는 TLS 핸드셰이크 시 암호화 전에 평문으로 전송되는 도메인 정보이므로 중간 장비가 읽고 필터링 가능
7. 조치 방법
- 근본 해결방법은..
- 협력업체 네트워크 담당자에게 13.201.10.254 게이트웨이 경로의 DPI/SNI 필터링 정책 확인 및 수정 요청
- 현실적인 해결방법은 ...
- retry 로직 추가, DNS가 매번 다른 IP를 주므로 retry 시 정상 노드로 자연스레 우회.
8. 조치 결과
- 고객사 네트워크 담당 협력 업체에 문의드리기에 현실적인 요건이 되지않아 retry 로직 추가 진행으로 해결