ServiceEntry 리스너 매칭 — 다섯 명제와 재현 시나리오

NS=se-verify
kubectl create ns $NS
kubectl label ns $NS istio-injection=enabled

# 테스트 클라이언트 (sleep 파드)
kubectl -n $NS apply -f https://raw.githubusercontent.com/istio/istio/master/samples/sleep/sleep.yaml
# (폐쇄망이면 curl 가능한 아무 이미지로 대체)
kubectl -n $NS wait --for=condition=ready pod -l app=sleep --timeout=120s
POD=$(kubectl -n $NS get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')

kubectl -n $NS apply -f - <<'EOF'
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: tls-a}
spec:
  hosts: ["one.example.com"]
  ports: [{number: 443, name: tls, protocol: TLS}]
  location: MESH_EXTERNAL
  resolution: DNS
---
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: tls-b}
spec:
  hosts: ["two.example.com"]
  ports: [{number: 443, name: tls, protocol: TLS}]
  location: MESH_EXTERNAL
  resolution: DNS
EOF

istioctl proxy-config listeners $POD -n $NS --port 443 -o json \
  | jq '[.[] | {name, lf: [.listenerFilters[]?.name],
         chains: [.filterChains[]? | .filterChainMatch.serverNames]}]'

kubectl -n $NS apply -f - <<'EOF'
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: squid-wrong-tls}
spec:
  hosts: ["squid.gw-zone.example"]
  ports: [{number: 3128, name: tls, protocol: TLS}]   # 일부러 잘못 선언
  location: MESH_EXTERNAL
  resolution: DNS
EOF

# 리스너 확인 — tls_inspector + serverNames 체인이 생겼는지
istioctl proxy-config listeners $POD -n $NS --port 3128 -o json \
  | jq '[.[] | {name, lf: [.listenerFilters[]?.name],
         chains: [.filterChains[]? | .filterChainMatch.serverNames]}]'

# 평문 CONNECT 시도
kubectl -n $NS exec $POD -c sleep -- \
  curl -m 5 -sv -x http://squid.gw-zone.example:3128 https://api.example.com/ -o /dev/null

kubectl -n $NS apply -f - <<'EOF'
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: squid-no-addr}
spec:
  hosts: ["squid.gw-zone.example"]
  ports: [{number: 3128, name: tcp, protocol: TCP}]   # addresses 의도적 생략
  location: MESH_EXTERNAL
  resolution: DNS
EOF

# (1) 와일드카드 확인
istioctl proxy-config listeners $POD -n $NS --port 3128
# 기대: ADDRESSES=0.0.0.0  PORT=3128  DESTINATION=Cluster: outbound|3128||squid.gw-zone.example

# (2) 발신측에는 DNS 결과가 있음을 대조 (P3의 "두 테이블" 검증)
istioctl proxy-config endpoints $POD -n $NS --cluster "outbound|3128||squid.gw-zone.example"
# 기대: 실 VIP가 보임. 반복 실행 시 GSLB 로테이션 따라 바뀜 — 그래도 (1)은 0.0.0.0 그대로

# (3) 하이재킹: SE와 무관한 IP:3128
kubectl -n $NS exec $POD -c istio-proxy -- pilot-agent request GET stats \
  | grep 'outbound|3128||squid' | grep upstream_cx_total          # 사전값 기록
kubectl -n $NS exec $POD -c sleep -- sh -c 'curl -m 4 -s telnet://192.0.2.55:3128; echo rc=$?'
kubectl -n $NS exec $POD -c istio-proxy -- pilot-agent request GET stats \
  | grep 'outbound|3128||squid' | grep upstream_cx_total          # 사후값 비교

# S3의 squid-no-addr 유지한 채 두 번째 추가
kubectl -n $NS apply -f - <<'EOF'
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: other-proxy-no-addr}
spec:
  hosts: ["other-proxy.partner.example"]
  ports: [{number: 3128, name: tcp, protocol: TCP}]
  location: MESH_EXTERNAL
  resolution: DNS
EOF

# (1) 리스너는 여전히 1개 — 어느 클러스터를 가리키는지 확인
istioctl proxy-config listeners $POD -n $NS --port 3128
# 기대: 0.0.0.0_3128 한 줄뿐, DESTINATION은 둘 중 하나만

# (2) 충돌 검출
istioctl analyze -n $NS
kubectl -n istio-system logs deploy/istiod --since=5m | grep -i conflict | head

kubectl -n $NS apply -f - <<'EOF'
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: squid-no-addr}
spec:
  hosts: ["squid.gw-zone.example"]
  addresses: ["198.51.100.10/32", "198.51.100.11/32"]   # GSLB VIP 집합 (실환경 값)
  ports: [{number: 3128, name: tcp, protocol: TCP}]
  location: MESH_EXTERNAL
  resolution: DNS
EOF

istioctl proxy-config listeners $POD -n $NS --port 3128
# 기대: 198.51.100.10:3128, 198.51.100.11:3128 — VIP별 리스너, 0.0.0.0 소멸

kubectl -n $NS exec $POD -c sleep -- sh -c 'curl -m 4 -s telnet://192.0.2.55:3128; echo rc=$?'
# 기대: 이제 미스 → ALLOW_ANY면 직행 시도 후 timeout, REGISTRY_ONLY면 즉시 차단
#       (S3과 달리 squid 클러스터 카운터가 증가하지 않음)

kubectl delete ns $NS