---
title: Outbound 집약 설계서 — Istio Egress Gateway로 Squid 경로 일원화
date: 2026-07-16
type: guide
domain: istio
tags: [egress, squid, forward-proxy, http-connect, egress-gateway, authorization-policy, migration]
---


> [!note] 원본은 스타일링된 HTML 설계서
> 이 글의 본체는 설계서 전문이다. 색 규약(amber = 프록시가 읽는 구간, teal = 프록시에 불투명한 구간) 기반 다이어그램 7종, 실측 바이트 캡처, 트러블슈팅 표를 포함한다.
>
> **[→ 전문 보기 (egress-gateway-squid-consolidation-guide.html)](files/egress-gateway-squid-consolidation-guide.html)**
>
> 이 페이지는 핵심 요약본.

## 한 문단 요약

바꾸는 것은 경로이지, 프록시가 아니다. GW존 Squid와 앱의 `HTTP_PROXY` 설정은 그대로 두고, 각 워커노드에서 GW존으로 직행하던 CONNECT 트래픽을 sidecar가 가로채 전용 egress 노드의 egress gateway를 경유시킨다. 완료 조건은 워커노드 → GW존 방화벽 ACL 제거 — 방화벽 대상이 "클러스터 전체"에서 "egress 노드 몇 대"로 줄어든다. 체이닝은 A안(앱이 CONNECT를 그대로 만들고 gateway는 `squid:3128`로 가는 TCP 경유지)을 채택했다. Istio 공식 지원 패턴이라 EnvoyFilter가 필요 없고 앱 무변경이다. 대가는 gateway가 최종 목적지를 전혀 모른다는 것 — 도메인 정책은 계속 Squid팀 ACL의 영역이고, gateway 층은 "누가 이 경로를 쓰는가"(AuthorizationPolicy, SPIFFE 신원)만 담당한다. 이 역할 분리가 조직 구조와 1:1로 일치한다.

## 구성

| 장 | 주제 | 핵심 |
|---|---|---|
| 00 | 요약과 결정사항 | 결정 5건과 근거 표 |
| 01 | forward proxy와 HTTP_PROXY | env는 OS 기능이 아니라 라이브러리 관례, 등록소 부재, NO_PROXY는 예외 목록 |
| 02 | CONNECT의 실제 | 평문/암호화 두 국면, 실측 바이트, 프록시가 보는 것과 못 보는 것 |
| 03 | 목표 아키텍처 | 경로 집약(Squid 대체 아님), A안 vs B안 비교 |
| 04 | Istio 구성 상세 | 객체 4종(ServiceEntry·DR·Gateway·VS)의 홉별 배선 · SE 매칭/발신 두-테이블 모델 · 층위 읽기 · exportTo 정합 + 검증 명령 |
| 05 | 워크로드 단위 통제 | 신원은 인증서에만 실린다 — mTLS가 AuthorizationPolicy의 전제 |
| 06 | 무장애 전환 절차 | 9단계, VirtualService 삭제 = 즉시 롤백인 구간 설계 |
| 07 | 운영 유의사항 | Calico 이중 잠금, 타임아웃 3층, 감사 추적 단절, 에러 시그니처 |
| 08 | 부록 | 트러블슈팅 표 · 용어집 |

## 핵심 결정 5건

| 항목 | 결정 | 근거 |
|---|---|---|
| 체이닝 방식 | A안 — 앱 CONNECT 유지, gateway는 TCP 경유지 | 공식 패턴 · 앱 무변경 · 무장애 원칙 |
| gateway 홉 보안 | `ISTIO_MUTUAL`, day-one 적용 | 워크로드 단위 통제의 유일한 전제. 롤백 안전판이 살아있는 초기가 검증 비용 최저 |
| 워크로드 통제 | AuthorizationPolicy는 맨 마지막, 관찰된 실사용 신원으로 작성 | dry-run 부재 → "관찰 → 작성 → 적용"이 사실상의 dry-run |
| 역할 분리 | 목적지 정책 = Squid팀 ACL · 사용 주체 정책 = 플랫폼팀 | 조직 구조와 기술 경계가 1:1 |
| 롤백 원칙 | 기존 노드 ACL 생존 중 VirtualService 삭제 = 즉시 원경로 복귀 | 따라서 ACL 제거는 반드시 마지막 단계 |

## 설계의 기술적 토대 네 가지

1. **CONNECT는 통로 개설 요청이지 HTTP 요청 전달이 아니다.** 200 응답 순간 그 커넥션은 HTTP이기를 멈추고 원시 바이트 릴레이가 된다. 그래서 gateway(A안)는 목적지를 모르고, TLS는 앱–origin 간 end-to-end로 성립한다.
2. **신원은 인증서에만 실린다.** AuthorizationPolicy의 `source.namespaces` 매칭은 IP 조회가 아니라 클라이언트 인증서 SPIFFE ID 문자열 파싱이다. plain TCP에는 추출할 원료가 없다 — 홉 1을 day-one에 `ISTIO_MUTUAL`로 만든 이유.
3. **강제력은 방화벽에서 나온다.** egress gateway를 세우는 날이 아니라 워커노드 ACL을 제거하는 날 보안 이득이 실현된다. mesh 밖 경로(sidecar 미주입·hostNetwork)는 Calico GlobalNetworkPolicy로 이중 잠금.
4. **DNS의 답은 발신에만 유입된다.** sidecar 안에는 테이블이 둘 — 리스너(매칭, 키는 사람이 적는 `addresses`)와 클러스터(발신, `resolution: DNS`가 STRICT_DNS 주기 해석). 매칭 키를 DNS로 만들 수 없는 이유는 DNS에 전칭 질의가 없기 때문이다. GSLB 가변 A레코드 대응(VIP 집합 열거)의 출발점이자, addresses 생략이 `0.0.0.0:3128` 와일드카드 하이재킹이 되는 이유.

## 개정 이력

- **2026-07-22 (v2)** — Part 04 대폭 확장. ① 4.2: 단일 IP 고정 전제를 **GSLB VIP 집합**으로 교체하고, `addresses`(매칭)와 `resolution: DNS`(발신)의 두-테이블 모델·addresses 부재의 3상태(공존/와일드카드 하이재킹/정의 충돌)·GSLB 대응 3택과 드리프트 감지 스크립트 추가 ② 4.6 신설: Gateway의 TLS는 홉② 포장 — 프록시 대화를 HTTP로 읽는 주체는 전 구간에서 Squid뿐 ③ 4.7 신설: exportTo 세 객체(SE·VS·DR) 정합 규칙과 `"."`이 불변 멤버인 이유(gateway 자신이 홉③의 SE 소비자) ④ 트러블슈팅 표에 "mTLS 성공 직후 종료 = SE exportTo `"."` 누락" 추가 ⑤ 7.1 Calico `nets`를 VIP 집합으로 정렬
- **2026-07-16 (v1)** — 최초 게시

## 관련 문서

- [HTTPS_PROXY 통신 흐름 실측 가이드 — CONNECT 이후 · 연결 재사용 · 재현 랩](/docs/networking/https-proxy-connect-flow-and-lab/) ([원문 HTML](/docs/networking/https-proxy-connect-flow-and-lab/files/https-proxy-connect-flow-and-lab.html)) — 이 설계서의 후속 실측. "동시 터널 수"가 용량 산정 단위인 이유를 5케이스 매트릭스로 증명
- [HTTP Tunneling — CONNECT 기초·Squid 실습](/docs/networking/http-tunneling-basics/) — Part 01–02의 배경을 실습으로
- [TLS 1.3 over Squid tunnel](/docs/networking/tls13-over-squid-tunnel/) — 터널 안 TLS의 실측
- [Egress 4-CRD 멘탈모델](/docs/istio/egress/crd-mental-model/) — Part 04 객체 배선의 원리
- [DNS GSLB 재현 랩](/docs/istio/egress/dns-gslb-repro-lab/) — 4.2 GSLB 가변 A레코드 대응의 실측 기반 (ServiceEntry resolution·플립 동작)
- [ServiceEntry 리스너 매칭 — 다섯 명제와 재현 시나리오](/docs/istio/egress/se-listener-matching-verification/) — 4.2 본문이 `se-listener-matching-verification.md`라는 이름으로 참조하는 동반 검증 문서 (S1~S5 재현 절차)
- [Egress 리소스 관리 모델 — exportTo 중앙 관리와 목적별 Service 분리](/docs/istio/egress/egress-resource-management/) ([원문 HTML](/docs/istio/egress/egress-resource-management/files/egress-gateway-resource-management.html)) — 이 설계서의 후속 운영 모델. 4.2·4.7을 전제로 CR을 몇 벌, 어디에 둘 것인가와 Service 분리 기준을 정의
- [DB 연결은 egress 경유 제외 — excludeOutboundPorts 타당성 검토](/docs/istio/egress/db-egress-exclusion/) ([원문 HTML](/docs/istio/egress/db-egress-exclusion/files/db-egress-exclusion-proposal.html)) — 이 설계서 체계의 **적용 범위 결정**. 외부 HTTPS는 이 설계대로 gateway 경유를 유지하되, DB(L4 장수명 커넥션)는 태우지 않는 근거
- [Calico NP 기반 DB 접근 통제 — 구성·검증·운영 가이드](/docs/k8s/calico-db-access-control/) ([원문 HTML](/docs/k8s/calico-db-access-control/files/calico-db-access-control.html)) — Part 07의 **Calico 이중 잠금과 같은 계층**. mesh를 태우지 않는 경로(DB 직결)를 GNS·GNP·NP로 통제하는 구성 가이드
- [Egress HTTPS 패턴 지도](/docs/istio/egress/https-pattern-map/) — 이 설계(forward proxy 체이닝)가 기존 4패턴과 어떻게 다른지 비교할 기준점