[네트워크 실무] Bluemax 방화벽 세션 드랍 원인 분석 (feat. TCP 3-way Handshake)

 

[네트워크 실무] Bluemax 방화벽 세션 드랍 원인 분석 (feat. TCP 3-way Handshake)

안녕하세요. 오늘은 현업 네트워크 엔지니어라면 한 번쯤은 반드시 마주치고, 또 골머리를 앓게 되는 주제인 '방화벽 세션 드랍'에 대해 이야기해 보려 합니다.
20년 가까이 현역으로 랜선을 찍어오고 다양한 인프라 환경을 구축하면서 뼈저리게 느낀 점이 하나 있습니다. 네트워크 장비, 특히 패킷은 절대 거짓말을 하지 않는다는 것입니다. 시스템이나 애플리케이션 담당자들은 종종 "방화벽에서 막힌 것 같아요"라고 쉽게 이야기하지만, Bluemax 같은 방화벽 로그에서 명확한 이유 없이 'Drop'이 뜬다면 결국 우리는 네트워크의 가장 기본인 TCP 3-way Handshake로 돌아가서 원인을 찾아야 합니다.

방화벽 세션드랍

 

1. 방화벽의 깐깐한 장부 관리 (Stateful Inspection)

단순히 IP와 포트만 검사하던 예전의 레거시 라우터들과 달리, 현대의 방화벽은 세션의 상태(State)를 추적하는 상태 기반 검사(Stateful Inspection)를 수행합니다.
정상적인 TCP 통신은 SYN -> SYN-ACK -> ACK라는 정해진 인사 과정을 거칩니다. 방화벽은 이 첫인사부터 자신의 세션 테이블(장부)에 꼼꼼하게 기록해 둡니다. 제 경험상, 알 수 없는 세션 드랍의 80% 이상은 이 깐깐한 장부 관리 원칙을 통신 양단이 지키지 않았을 때 발생합니다. 앞뒤 다 자르고 불쑥 패킷을 들이밀면, 방화벽은 "내 장부에 없는 녀석이네?" 하고 가차 없이 패킷을 버립니다. 보안 장비로서는 지극히 당연하고 올바른 동작인 셈이죠.

 

 

2. 실무에서 겪은 세션 드랍의 주범들

멀쩡해 보이는 통신이 방화벽에서 거부당하는 이유, 실무 관점에서 가장 잦은 원인 세 가지를 꼽아보겠습니다.

• 비대칭 라우팅 (Asymmetric Routing)
  개인적으로 트러블슈팅 과정에서 가장 피곤한 케이스라고 생각합니다. 나가는 경로와 들어오는 경로가 다를 때 발생하는데요. 클라이언트가 방화벽을 통해 SYN을 보냈는데, 서버가 응답하는 SYN-ACK는 다른 경로(예: L3 스위치 백본이나 우회 회선)를 타고 돌아오는 상황입니다.
  이렇게 되면 방화벽 입장에서는 SYN-ACK 과정을 보지 못했기 때문에, 이후 이어지는 통신을 비정상적인 흐름으로 간주하고 세션을 끊어버립니다. Bluemax 로그에 'Out-of-State'나 'Invalid TCP Flag'가 보인다면 십중팔구 이 녀석입니다. 방화벽 자체의 결함이라기보다 전체 네트워크 라우팅 설계가 꼬여있다는 방증이기도 합니다.

 

• 세션 타임아웃 (Session Timeout)
  DB 쿼리나 SSH 연결처럼 한 번 맺어두고 장시간 데이터를 주고받지 않는 'Idle' 상태에서 자주 터집니다. 방화벽은 메모리를 보호하기 위해 일정 시간 통신이 없으면 세션 테이블에서 해당 기록을 지웁니다. 그런데 양단 서버는 아직 연결된 줄 알고 한참 뒤에 데이터를 툭 보냅니다.
  보통 애플리케이션 개발자나 DB 담당자들과 원인을 두고 핑퐁 게임을 하게 되는 단골 소재죠. Bluemax뿐만 아니라 Fortigate나 타 벤더의 방화벽 장비에서도 원리는 동일하게 적용됩니다.

 

• 비정상적인 TCP 플래그 조합
  스캐닝 툴이나 특정 애플리케이션의 버그로 인해 표준에 맞지 않는 플래그(예: SYN과 FIN 동시 전송)가 날아올 때가 있습니다. 이런 비정상적인 패킷은 방화벽이 훌륭하게 방어해 낸 것이니 오히려 안심해도 되는 로그입니다.
  
  
  

3. 엔지니어의 문제 해결 노하우

수많은 장애를 처리하며 얻은 저만의 트러블슈팅 철학은 "GUI 로그에만 전적으로 의존하지 말자"입니다. 대시보드에 찍힌 로그는 현상의 결과일 뿐, 원인은 다른 곳에 있을 때가 많습니다.

 

• 라우팅의 큰 그림 보기: 비대칭 라우팅이 의심되면 방화벽 하나만 쳐다보지 마시고, 출발지와 목적지 양방향에서 라우팅 트레이스를 떠서 경로를 완전히 파악해야 합니다.

 

• 세션 유지 시간 최적화: 타임아웃 문제라면 방화벽 정책에서 해당 서비스의 세션 타임아웃 값을 늘려주는 것도 방법이지만, 저는 가급적 서버나 애플리케이션 단에서 Keep-alive 설정을 켜는 것을 권장합니다. 그게 전체 네트워크 리소스를 관리하는 더 깔끔한 방법입니다.

 

• 패킷 까보기 (PCAP): 눈으로 직접 확인하기 전까지는 아무것도 확신하지 마세요. 방화벽 자체 캡처나 스위치 미러링을 통해 Wireshark로 tcp.flags 흐름을 쭉 따라가 보는 것만큼 확실한 방법은 없습니다.
  
  

결국 답은 패킷 안에 있습니다.
방화벽 트러블슈팅이 막막하게 느껴질 때도 있지만, 결국 해결의 실마리는 항상 네트워크의 기본기에 숨어있습니다.

오늘 하루도 장애 없는 평온한 네트워크 환경이 되시기를 바랍니다!

 

 

 

♥읽어주셔서 감사합니다♥
티스토리 댓글과 공감♥은 로그인이 필요 없습니다.
로그인하시면 구독 가능합니다.