개발자를 울리는 반쪽짜리 통신: 방화벽 정책과 비대칭 경로 해법

오늘은 개발자나 시스템 관리자라면 한 번쯤은 머리를 쥐어뜯었을 법한, 그러면서도 생각보다 흔하게 발생하는 IT 장애 사례를 들고 왔습니다. 바로 '방화벽 정책 누락'과 '비대칭 경로'가 만나 벌어진 외부 연동 실패 이야기입니다.

저도 최근에 비슷한 경험을 했습니다. 신규 API 연동 후 외부 파트너사 서버로 데이터를 전송하는데, 아무리 해도 연결이 되지 않는 겁니다. 처음에는 가끔 패킷 유실이 있더니, 나중엔 아예 연결 시도 타임아웃으로 이어지더군요. 신규 결제 모듈 도입이 늦어지면서 비즈니스 오픈 일정까지 차질을 빚게 되자, 심장이 쫄깃해지는 기분이었습니다.

서버 내부에서는 아웃바운드(Outbound) 패킷이 나가는 로그가 정상적으로 확인되는데, 정작 인바운드(Inbound) 응답 패킷은 감감무소식인 'Half-open' 상태. 마치 친구에게 편지를 보냈는데, 친구는 받았다고 연락도 없고 답장도 오지 않는 상황이랄까요? 문제는 여기에 있었습니다. 도대체 무엇이 우리의 패킷을 가로막고 있었을까요?

도대체 뭐가 문제였을까요? (주요 원인 분석)

밤샘 분석 끝에 밝혀진 주요 원인은 크게 두 가지였습니다. 바로 방화벽 정책 누락과 비대칭 경로(Asymmetric Routing)였죠.

1. 방화벽 정책 누락: 너무나도 흔한 실수

첫 번째 원인은 생각보다 단순했습니다. 신규 API 연동을 진행하면서 파트너사의 공인 IP 또는 특정 포트(예: TCP/443)가 우리 사내 방화벽의 허용 리스트에 추가되지 않았던 것입니다. 보통 새로운 외부 연동을 진행할 때 방화벽 정책 신청을 하는데, 이 과정에서 작은 오기입이나 누락이 발생하기 쉽습니다. 특히 급하게 진행되는 프로젝트에서는 더욱 그렇습니다. 방화벽은 들어오는 문과 나가는 문을 철저히 검사하는데, 나가는 문은 열려있어도 들어오는 문이 닫혀있다면, 응답 패킷이 다시 돌아올 수 없는 것이 당연한 이치입니다.

2. 비대칭 경로(Asymmetric Routing): 네트워크의 숨은 함정

이 부분이 사실 더 골치 아픈 문제였습니다. 비대칭 경로는 말 그대로 나가는 패킷의 경로와 들어오는 패킷의 경로가 다른 상황을 의미합니다. 예를 들어, 우리 서버에서 외부로 나가는 데이터는 A 경로를 타고 나가는데, 외부에서 우리 서버로 돌아오는 데이터는 B 경로를 타고 들어오는 경우죠.

"상태 기반(Stateful) 방화벽은 나간 기록이 없는 패킷을 침입으로 간주하여 차단(Drop)합니다."

우리 회사의 방화벽은 '상태 기반(Stateful)' 방화벽이었는데, 이 방화벽은 이전에 나간 패킷의 '상태'를 기억하고 있습니다. 그런데 비대칭 경로로 인해 전혀 다른 경로로 돌아온 응답 패킷을 보면, 방화벽은 "나는 이 패킷이 나간 것을 본 적이 없는데? 이건 외부에서 불법적으로 들어오는 패킷이군!"이라고 판단하여 무자비하게 차단해 버리는 겁니다. 이 경우, 서버 입장에서는 패킷이 나갔는데 돌아오지 않는 Half-open 상태가 됩니다.

3. 작업적 원인: 작은 실수들이 모여 큰 장애로

이 외에도 방화벽 정책 신청 시 포트 번호 오기입, 혹은 네트워크 이중화 경로를 사용하는 경우 라우팅 테이블 업데이트 누락 등 다양한 작업적 실수가 원인으로 작용할 수 있습니다. 결국, 시스템의 복잡도가 높아질수록 이런 작은 휴먼 에러가 치명적인 장애로 이어질 수 있다는 교훈을 다시 한번 얻었습니다.

문제 해결을 위한 탐정놀이 (분석 내용)

이 복잡한 문제를 해결하기 위해 저와 팀원들은 몇 가지 분석 도구를 활용해 탐정처럼 원인을 추적했습니다.

1. 네트워크 경로 추적: Traceroute와 MTR

가장 먼저 시도한 것은 `traceroute`나 `mtr` 명령어를 통해 파트너사 서버까지의 네트워크 경로를 추적하는 것이었습니다. 이 도구들을 사용하면 패킷이 어떤 라우터를 거쳐 어디까지 도달하는지 단계별로 확인할 수 있습니다. 저희의 경우, 파트너사 게이트웨이 직전에서 패킷이 멈추는 것을 확인하고, '아, 우리 네트워크를 벗어나기 전이나, 파트너사 네트워크에 진입하기 직전에서 문제가 있구나' 하고 힌트를 얻을 수 있었습니다.

2. 패킷 캡처: Tcpdump로 들여다본 속사정

다음 단계는 `tcpdump`를 이용한 패킷 캡처였습니다. 서버에서 파트너사로 SYN 패킷을 보내는 것은 확인되는데, 파트너사에서 보내는 SYN-ACK 패킷이 우리 서버로 돌아오지 않는 명백한 'Half-open' 상태를 두 눈으로 확인할 수 있었습니다. 이로써 서버 자체의 문제는 아니고, 네트워크 어딘가에서 응답이 차단되고 있다는 확신을 가질 수 있었죠.

3. 방화벽 로그 조회: 범인은 이 안에 있어!

가장 결정적인 증거는 방화벽 관리 콘솔에서 찾았습니다. 해당 목적지 IP에 대한 로그를 조회하니, 'Action: Deny' 또는 'Invalid State'와 같은 드롭 로그가 끊임없이 포착되었습니다. 이는 방화벽이 특정 패킷을 명시적으로 차단했거나, 비대칭 경로로 인해 상태를 알 수 없어 차단했다는 명확한 증거였습니다. "범인은 방화벽이야!"를 외치는 순간이었습니다.

그렇게 해결되었습니다! (조치 및 개선)

원인을 정확히 파악하자 조치는 비교적 신속하게 진행될 수 있었습니다.

1. 긴급 조치: 불부터 끄자!

• 방화벽 정책 즉시 추가: 방화벽 관리팀에 연락하여 누락된 파트너사 공인 IP와 서비스 포트 정책을 즉시 추가했습니다.
• 스태틱 라우팅 강제 지정: 비대칭 경로가 확인된 구간에 대해서는 특정 인터페이스로만 입출력되도록 스태틱 라우팅(Static Route)을 강제 지정하여 경로를 일원화했습니다.

2. 구조적 개선: 재발 방지를 위한 시스템 변경

• 방화벽 정책 객체(Object)화: 유사한 외부 파트너 그룹을 하나의 객체로 묶어 관리함으로써, 개별 IP 추가 시 발생할 수 있는 정책 누락 가능성을 줄였습니다.
• L4/L7 스위치 세션 유지(Persistence) 설정: 이중화된 네트워크 환경에서는 L4/L7 스위치에 세션 유지(Persistence) 설정을 통해 동일한 경로로 트래픽이 처리되도록 보장하여 비대칭 경로 발생을 원천 차단했습니다.

3. 재발 방지: 사람과 기술의 조화

• 방화벽 정책 신청 가이드 배포: 모든 팀원에게 정확한 방화벽 정책 신청 가이드를 배포하여, 신청 단계에서부터 오류를 최소화하도록 교육했습니다.
• 통신 상태 모니터링 자동화: 주요 외부 연동 접점에 대해서는 `telnet` 또는 `nc (Netcat)` 스크립트를 주기적으로 실행하여 통신 상태를 모니터링하고, 이상 징후 발생 시 즉시 알림을 받을 수 있도록 자동화 시스템을 구축했습니다.

마치며

결과적으로 신규 API 연동은 무사히 완료되었고, 결제 모듈 도입도 정상적으로 이루어졌습니다. 하지만 이 과정에서 방화벽 정책의 중요성, 그리고 복잡한 네트워크 환경에서 비대칭 경로가 얼마나 치명적인 영향을 미칠 수 있는지 다시 한번 깨닫게 되었습니다. 눈에 보이지 않는 네트워크 경로와 정책 하나하나가 서비스의 생사를 결정할 수 있다는 사실을 잊지 말아야겠습니다.

이 경험을 통해 얻은 교훈은 단순히 기술적인 문제를 해결하는 것을 넘어, '작은 디테일'이 '큰 비즈니스 임팩트'로 이어질 수 있다는 IT 운영의 본질적인 중요성을 다시금 일깨워 주었습니다. 여러분도 비슷한 상황에 처했을 때, 이 글이 조금이나마 도움이 되기를 바랍니다!

자주 묻는 질문 (FAQ)

Q1: 방화벽 정책을 왜 자주 빼먹거나 잘못 기입하나요?
A1: 새로운 서비스 연동, IP 변경, 포트 변경 등 다양한 변경 작업이 빈번하게 발생하기 때문입니다. 또한, 복잡한 시스템 구조, 급박한 배포 일정, 그리고 휴먼 에러가 겹치면서 정책 누락이나 오기입이 발생하기 쉽습니다. 철저한 가이드라인과 자동화된 검증 절차가 중요합니다.

Q2: 비대칭 경로는 왜 생기나요?
A2: 네트워크 환경이 복잡해지면서 발생합니다. 주로 다중의 인터넷 회선, 로드 밸런서(L4/L7 스위치), VPN 터널, 또는 잘못된 라우팅 설정(라우팅 테이블 누락/오류) 등이 원인이 될 수 있습니다. 나가는 경로와 들어오는 경로가 최적화 로직이나 장비 구성상의 이유로 달라질 때 나타납니다.

Q3: `tcpdump`로 뭘 확인해서 Half-open 상태를 알 수 있었나요?
A3: `tcpdump`를 통해 TCP 3-Way Handshake 과정을 관찰했습니다. 클라이언트(우리 서버)가 SYN 패킷을 보내는 것은 확인되지만, 서버(파트너사)로부터 SYN-ACK 패킷이 돌아오지 않는 것을 포착했습니다. 이는 연결 시도는 있었으나, 서버로부터의 응답이 중간에 차단되었음을 명확히 보여주는 증거입니다.

Q4: Half-open 상태가 정확히 뭔가요?
A4: Half-open 상태는 TCP 연결 설정 과정에서 클라이언트가 서버로 SYN 패킷을 보냈지만, 서버로부터 SYN-ACK 응답을 받지 못하여 연결이 완전히 수립되지 않은 상태를 의미합니다. 클라이언트는 연결 시도를 인지하고 있지만, 서버로부터의 응답이 없거나 중간에 유실/차단되어 통신이 이루어지지 않는 '반쪽짜리' 연결 상태입니다.

Q5: 이런 외부 연동 문제를 방지하려면 어떻게 해야 하나요?
A5: 첫째, 사전 정의된 절차 준수: 방화벽 정책 신청 및 변경 가이드를 명확히 하고 모든 팀원이 따르도록 합니다. 둘째, 자동화된 모니터링: 주요 외부 연동 지점에 대한 통신 상태 모니터링을 자동화하여 이상 징후를 조기에 감지합니다. 셋째, 정기적인 검토 및 감사: 방화벽 정책 및 네트워크 라우팅 테이블을 정기적으로 검토하여 불필요하거나 잘못된 설정을 수정합니다. 넷째, 명확한 책임 분리: 네트워크, 보안, 개발, 운영 팀 간의 책임과 역할을 명확히 하고 긴밀한 협업 체계를 구축하는 것이 중요합니다.