내용 보완: 2026년 10월 16일
VIP 연결 성공이 서버 정상이라는 뜻은 아닙니다
BIG-IP의 Standard virtual server는 클라이언트 측과 서버 측 연결을 분리하는 full proxy 구조를 사용합니다. 클라이언트가 VIP에 TCP 연결을 맺는 단계와 실제 pool member에 요청이 전달되는 단계는 구분해야 합니다. 연결 결과는 virtual server 유형·프로파일·pool 상태·설정에 따라 달라질 수 있습니다.
장애 점검 순서
- Virtual server가 Standard인지, 적용된 TCP·HTTP·TLS 프로파일은 무엇인지 확인합니다.
- Pool과 member의 헬스 상태, 모니터 대상 포트·요청·성공 조건을 확인합니다.
- 단순 telnet 연결과 실제 HTTP 등 애플리케이션 요청 결과를 비교합니다.
- 클라이언트 측 연결과 서버 측 연결을 분리하여 로그·패킷을 확인합니다.
따라서 “서버가 내려갔는데 VIP에 접속된다”는 관측만으로 장비 결함이나 서비스 정상 여부를 단정할 수 없습니다. 아래의 당시 운영 경험은 이 구분을 놓쳤을 때의 사례로 읽어주세요. 운영 판단은 해당 TMOS 버전과 구성의 실제 응답을 기준으로 합니다.
공식 참고: F5 Standard와 Performance L4 virtual server 동작. 네트워크 운영 가이드에서 배치와 트래픽 흐름을 함께 확인하세요.
기존 기록과 설명
내가 경험했던 수백개의 장비 중에 F5사의 Big-ip i2600장비가 있었다. 라이센스는 LTM, ASM, GSLB를 사용해봤는데, 이 중 오늘 얘기해보고자 하는건 LTM이다.
Local Traffic Manager..였나? 무튼 우린 L4라고 흔히 부르며 로드밸런싱을 위해 사용했고, 필요에 따라 XFF설정을 해주기 위해 인증서를 올리는 나름 L7의 기능까지 사용을 했다.
이 장비를 사용하다보면 꽤 좋다. 물론 저 2600장비는 소규모 운영에서는 전혀 무리가 없지만 규모가 제법 되는 곳에서 사용하기에는 그리 좋은 장비는 아니다. 하지만 그건 스펙의 차이일 뿐 기능상의 문제는 없으니…
내가 얘기하고 싶은건 Standard Mode이다. F5에서의 Standard Mode를 간단하게 PPT에서 박스와 화살표로 그림을 그려왔다.
우리는 일반적으로 L4에서 패킷을 Forwarding(전달)만 해주기 위해서는 Performance L4라는 기능을 사용한다.
하지만 경우에 따라서 위와 같은 방식을 사용하게 되는데 그것이 Standard 방식이다.
이 방식은 L4에서 클라이언트와 서버가 세션을 맺게 하는 것이 아니라, L4가 각 사이드와 각각 세션을 맺어서 통신을 하는 방식이다.
보통 이런 방식을 취할 경우는 L4에서 패킷을 까봐야할 경우가 있을 때다. 이 이상의 심도 깊은 이야기는 나중에 따로 하도록 하자.(내 밑바닥이 드러나는게 싫어서가 아니라는 것을 알아줬으면 좋겠다;)
물론 내가 말하고자 하는건 방식에 대한 설명이 아니다.
본격적인 이야기는 지금부터인데, 어느 날, 신규 L4 서비스를 올리고나서 얼마 지나지 않은 날이었다. 문의가 왔다.
서버에서 서비스 데몬을 내렸는데 VIP로 텔넷이 된다 라는 얘기였다. 황당했다. 무슨 이런 일이 있을 수가 있지? 당연히 Real Server에서의 헬스체크가 죽으면 VIP는 그 즉시 죽어버려야 하는게 정상인데, 버젓이 텔넷이 된단다..
나중에 알고보니 간혹 Standard방식이 위와 같이 각각에 대해 세션을 맺고 있다보니 텔넷이 되는 경우가 있다고 한다.
실제로 통신이 되는 것은 아니고 텔넷이 되는 것처럼 보여지는 것이라는..
아무튼 이 부분은 맹점인 것은 확실하다. 실제 우리가 아는 원리대로 구현되지 않은 것이 분명하니…
이런 일도 있으니 누군가 이런일이 있을 때 나의 글을 읽고 바로 안심할 수 있었으면 좋겠다는 생각에 글을 남겨본다.