내부 서비스 구조에서 App 서버가 사설 L4 VIP를 바라보는 환경은 흔하다.
내부 LB 계층을 통해 여러 App 서버 간 트래픽을 중계하는 구조에서는
App 서버가 App 서버의 VIP를 직접 호출하는 일이 자연스럽게 발생한다.

그런데 이 구조에서 특정 상황에서만 트래픽이 drop되는 장애가 발생한다.
주로 아래 작업 후 자주 나타난다:

• L2 스위치 교체
• uplink 포트 변경
• VLAN 재배치
• 포트 구성 누락
• L4 밑단 스위치 구조 변경

표면적으로는 L4도 정상, App 서버도 정상, Health Check도 정상인데
정작 “App 서버 → L4 VIP” 요청만 동작하지 않는다.

이 문제의 근본 원인은 매우 단순하다.

L4로 들어온 요청은 반드시 L4를 통해 나가야 한다.
내부 App 서버가 같은 L2에 있을 경우, 응답 패킷이 L4를 우회하면 drop 된다.

이 글에서는
이 비대칭 라우팅(asymmetric routing)이 왜 생기는지,
왜 proxy ip가 반드시 필요한지,
어떤 구조에서 재현되는지
실제 장애 사례 기준으로 정리했다.

---

1. 장애 시나리오 — 내부 App 서버에서만
VIP 호출이 실패한다

외부 사용자 → L4 VIP → App 서버
이 흐름은 정상 동작한다.

문제는 내부에서 내부를 부르는 구조다.

예시:

• App1 → L4 VIP(내부 사설 VIP) → L4 → App2
• 그런데 App2 → App1 응답이 L4를 거치지 않고 direct로 보내짐 → drop 발생

즉, 내부 App 간의 흐름만 죽는다.

이 현상은 L4 장비 세션 구조 + L2 스위치 동작 특성 두 개가 맞물리면서 발생한다.

---

2. 기본 구조 이해 — L4 밑단 L2 스위치와
App 서버들

다음과 같은 구성은 매우 흔하다.

• L4 밑단에 단일 L2 스위치가 있고
• 그 아래 App 서버 여러 개가 같은 VLAN에 존재
• L4 VIP는 이 서버들을 대상으로 로드밸런싱 수행

여기서 핵심은 다음이다.

같은 L2에 있는 서버들은 서로를 직접 ARP로 찾아갈 수 있다.

즉, App2는 App1의 MAC 주소를 직접 알고 있으므로
굳이 L4를 경유할 이유가 없다.

이게 문제의 시작이다.

---

3. 트래픽 흐름이 실제로 어떻게 깨지는가?

내부 App 서버(App1)에서 내부 VIP를 호출한다고 해보자.

흐름은 다음과 같다:

1. App1 → L4 VIP:80 (요청 정상)
2. L4 → App2로 LB 수행 (정상)
3. App2 → App1 응답 시
   • 같은 L2이므로 App1의 MAC을 직접 가지고 있음
   • 따라서 L4를 거치지 않고 direct로 응답
4. L4 세션 테이블에는 “App2 → App1 direct 흐름”이 없음
5. 결과적으로 패킷 drop

즉,

요청은 L4를 거쳤는데, 응답은 L4를 거치지 않는 비대칭 경로가 발생함 → drop

이 문제는 NAT 기반 L4 구조에서 반드시 재현된다.

---

4. L4는 direct 응답을 왜
drop하는가?

L4 NAT 모드에서 VIP 트래픽은 세션 기반이다.

• 요청(Request)을 받은 VIP
• 내부 Real Server로 전달
• 응답(Response)이 다시 VIP를 통해 돌아와야만
• L4의 NAT 테이블과 세션 테이블이 일치함

하지만 App2가 L4를 우회해 App1로 direct 응답을 보낸다면:

• L4 NAT 테이블에는 App1에 대한 응답 흐름이 존재하지 않음
• App1 입장에서는 “VIP에서 온 응답이 아닌 이상한 패킷”이 됨
• L4는 관련되지 않은 패킷이라고 판단해 drop

결과적으로 L4 NAT 구조가 깨지면서 통신 전체가 실패한다.

---

5. 해결책 — Proxy IP 구성

이 문제를 해결하는 유일하고 정석적인 방식이 바로 proxy ip 설정이다.

proxy ip의 역할은 다음과 같다:

L4 아래의 L2 스위치가, 동일 L2에 있는 App 서버들이 서로 통신할 때
반드시 L4를 통해 응답 패킷을 전달하도록 강제하는 기능.

구조적으로는 이렇게 바뀐다.

• App2가 App1로 응답을 내보내려 할 때
• L2 스위치가 바로 보내지 않고 proxy ip(L4)를 향해 전달
• L4가 NAT 테이블에 맞춰 App1으로 정상적으로 반환
• 대칭 흐름 복구

즉,

1. App1 → VIP 요청
2. VIP → App2 LB
3. App2 → proxy ip(L4)로 응답 강제
4. L4 → App1 반환
5. 세션 정상, drop 없음

이제 트래픽이 100% 대칭 구조가 된다.

---

6. uplink 변경, 스위치 교체 후 장애가 터지는 이유

uplink 포트가 바뀌면 다음 문제가 발생할 수 있다:

• proxy ip 설정이 uplink 포트에 적용되지 않음
• VLAN/ARP 테이블이 재학습되면서 L4 우회 경로가 재활성화됨
• 스위치가 “App 서버 간 direct 통신 가능”로 다시 판단
• 결국 App2 → App1 direct 응답이 부활함
• L4는 응답을 받지 못해 모든 요청 drop

즉,

L4 세션 기반 NAT 구조는 proxy ip가 무력화되는 순간 깨진다.

이 현상은 L4 장비 교체, 포트 이동, 스위치 교체에서 특히 자주 발생한다.

---

7. 운영자가 반드시 기억해야 하는 핵심 규칙

✔ 규칙 1

L4 vip 로 들어온 요청은 반드시 L4 vip로 나가야 한다.
이게 깨지면 세션 기반 NAT LB는 100% 실패한다.

✔ 규칙 2

같은 L2에 있는 App 서버들은 direct 응답이 가능하다.
따라서 반드시 proxy ip로 응답 경로를 L4로 되돌려야 한다.

✔ 규칙 3

uplink 포트 변경 = proxy ip 설정 검증 필수
현장에서 가장 자주 놓치는 부분이다.

✔ 규칙 4

내부 App 서버가 내부 VIP를 바라보는 구조에서는 proxy ip가 필수적이다.

---

8. 결론

내부 App 서버에서 내부 L4 VIP로 접근할 때만 발생하는 서비스 불가 현상은
복잡한 문제처럼 보이지만 실제로는 매우 단순한 원리다.

App 서버가 direct로 응답하려고 하기 때문에
L4 세션/NAT 구조가 깨져서 drop이 발생한다.

이 문제는 proxy ip 구성만 정확히 하면 완전히 해결된다.
uplink 포트 변경, 스위치 교체 작업 이후에는
proxy ip 설정이 포트 단위로 제대로 적용되었는지 반드시 확인해야 한다.

9. Proxy IP 적용 전·후 트래픽 흐름 요약

✅ [Proxy IP 적용 전] — 비대칭 라우팅 Flow 요약

1. App1 → L4 VIP로 요청 전송
2. L4 LB → App2로 요청 전달 (LB 동작은 정상)
3. App2 → 응답 전송 시, 같은 L2에 있으므로 L4를 우회하여 App1로 Direct 응답
4. L4 NAT 세션 테이블과 응답 경로가 불일치 → 세션 Broken
5. 결과: App1은 응답을 받지 못하고 트래픽 Drop 발생

📌 핵심 문제
App2가 응답을 L4를 거치지 않고 직접 보내서 요청/응답 경로가 비대칭이 되며 NAT 기반 세션이 깨짐.

---

✅ [Proxy IP 적용 후] — 대칭 라우팅 Flow 요약

1. App1 → L4 VIP로 요청 전송
2. L4 LB → App2로 요청 전달
3. App2 → 응답을 Proxy IP로 전송 (L2 스위치가 강제로 L4로 향하게 함)
4. Proxy IP → L4 LB로 응답 전달
5. L4 LB → App1로 정상 반환
6. 요청/응답 경로가 완벽한 대칭 구조 완성 → NAT 세션 정상 유지

📌 핵심 효과
Proxy IP가 응답 트래픽을 L4로 강제해 NAT 구조가 유지되므로 내부 App 간 VIP 호출도 안정적으로 동작.

🛠 마지막 수정일: 2025.11.15