백엔드 개발자가 네트워크 레이어까지 추적한 이유 — VoIP 지연 7초의 진짜 원인
배경
중소기업에서 백엔드 개발자는 애플리케이션 레이어만 보는 게 아니다.
이 글은 장애 원인이 코드가 아닌 네트워크 레이어에 있었음을 추적한 경험이다.
사무실 인터넷 전화 당겨받기에서 7초 지연이 발생했다. 전화 담당 기사는 포트 차단을 원인으로 지목했지만, 실제 원인은 전혀 다른 곳에 있었다.
1
2
TCP: 5060, 19600, 19700, 8080
UDP: 22500 ~ 24970
우리 외부망은 Juniper SSG-140 방화벽을 쓰고 있다.
포트 확인
방화벽 WebUI에서 기존 정책을 확인했다.
1
2
3
4
5
6
From Untrust To Trust, total policy: 6
ID Source Destination Service
11 Any Any VoIP_Service
VoIP_Service2
VoIP_Service3
ID 11번 정책에 이미 VoIP_Service가 등록되어 있었다.
서비스 내용을 확인해봤다.
1
2
3
4
5
TCP src port: 0-65535, dst port: 5060-5060
TCP src port: 0-65535, dst port: 19600-19600
TCP src port: 0-65535, dst port: 19700-19700
TCP src port: 0-65535, dst port: 8080-8080
UDP src port: 0-65535, dst port: 22500-24970
기사가 요청한 포트가 전부 이미 열려있었다.
포트 문제가 아니었다.
원인 분석
포트가 열려있는데 7초 지연이 발생한다면 다른 원인이 있다.
방화벽의 SIP ALG 설정을 확인했다.
1
2
3
Security → ALG → Basic
SIP [활성화 상태]
SIP ALG는 방화벽이 SIP 패킷을 중간에서 열어보고 수정하는 기능이다.
문제는 SIP 패킷 헤더는 수정하면서 바디 안의 IP/포트 정보는 따라가지 못하는 경우가 생긴다.
1
2
3
4
5
6
7
8
SIP 패킷 내부:
┌─────────────────────────────────┐
│ Header: 수정됨 │
│ Body: IP/포트 정보 불일치 │ ← 여기서 꼬임
└─────────────────────────────────┘
→ 상대방이 주소 불일치를 확인하는 데 7초 대기
→ 결국 지연 발생
도와주려다 오히려 신호를 꼬이게 만드는 케이스다.
해결
WebUI에서 SIP ALG 체크박스를 해제하고 Apply했다.
1
2
3
Security → ALG → Basic
→ SIP 체크 해제
→ Apply
이후 전화 당겨받기 테스트에서 7초 지연이 사라졌다.
마무리
포트 오픈 요청이 들어오면 일단 현황 확인부터 해야 한다. 기사가 열어달라고 해도 이미 열려있을 수 있다.
포트가 다 열려있는데도 VoIP 지연이 생기면 SIP ALG를 먼저 의심해볼 것. 방화벽 벤더마다 위치는 다른데 SSG 기준으로는 Security → ALG에 있다. 그리고 SSG는 방화벽 정책을 위에서부터 순서대로 매칭하기 때문에, ID 숫자가 아니라 리스트 상의 위치가 기준이라는 것도 알아둬야 한다.
포트가 열려있어도 전화가 안 되면, 방화벽이 중간에서 신호를 건드리고 있는 건 아닌지 확인해보자.