{
  "test_id": "T47",
  "verdict": "fail",
  "observed": "run1의 'CORRECTION(2026-07-05)' 규칙(DestinationRule/VS의 hop-gw 목적지 host를 registry FQDN인 hop-gw.<ns>.svc.cluster.local로 교정, ServiceEntry/Gateway/sniHosts는 literal homelab.local 유지)을 새 네임스페이스(istio-vt-t47-r2)에 그대로 적용해 재실행했다. twohop_https=200은 이번에도 성공했고, 교정 덕분에 CDS/EDS 레벨 결함은 실제로 해소됨을 확인했다: client의 outbound|8443||hop-gw.istio-vt-t47-r2.svc.cluster.local 클러스터는 (run1의 유령 클러스터와 달리) 이번에는 실제로 존재하고 hop-gw 파드 IP(10.255.159.138:8443)를 가리키는 HEALTHY 엔드포인트를 갖고 있었다. 그럼에도 pass_criteria의 핵심 요구('hop-gw에서 istio_tcp_connections_opened_total > 0')는 여전히 위반되었다: hop-gw의 access log는 0줄, istio_tcp_connections_opened_total=0, istio_requests_total=0이었고, hop-gw를 0 replica로 스케일해 파드를 완전히 삭제해도 client->mock 호출은 계속 twohop_https_gwdown=200을 반환했으며, 복구 후에도 동일했다(hop-gw 카운터는 여전히 0). CDS/EDS 교정만으로는 부족했던 근본 원인을 LDS 레벨에서 새로 규명했다: client 사이드카는 mock의 실제 ClusterIP(10.250.183.220)에 바인딩된 전용 리스너(10.250.183.220_443)를 갖고 있고, 이 리스너에는 SNI 매치가 전혀 없는 단일 default filterChain만 존재해 outbound|443||mock.istio-verify-ext.svc.cluster.local로 바로 TCP 프록시된다. 'mesh' 게이트웨이 VS의 SNI 매치(hop-gw로의 라우팅)는 0.0.0.0_443 와일드카드 리스너에만 존재하는데, Envoy의 original_dst 내부 리디렉션은 목적지 IP와 정확히 일치하는 더 구체적인 per-ClusterIP 리스너를 항상 우선 적용하므로 이 SNI 매치 경로 자체가 평가되지 않는다. 즉 ServiceEntry로 등록한 'mock.istio-verify-ext.svc.homelab.local'이 실제로는 클러스터 DNS 도메인(homelab.local)을 통해 이미 mesh registry에 등록된 진짜 k8s Service(mock)의 ClusterIP로 그대로 해석(resolve)되기 때문에, 이 특정 조합(ServiceEntry+Gateway+VS+DR)이 내부 게이트웨이로 강제 우회시키는 메커니즘 자체가 도메인 교정 여부와 무관하게 구조적으로 성립하지 않음을 확인했다. client->echo in-mesh 호출은 정상 200 + 정상 L7 access log를 남겨 관측 파이프라인 자체는 건강함을 재확인했다. client의 proxy-config route에는 mock host용 HTTP route가 0개, upstream_rq_retry 카운터도 존재하지 않아 'TLS PASSTHROUGH에서 VS.http.retries가 컴파일조차 안 되어 조용히 무시된다'는 서브 클레임은 hop-gw 경유 여부와 무관하게 이번에도 독립적으로 지지되었다. 이는 인프라 결함(blocked 사유)이 아니라 재현 가능한, 근본 원인이 규명된 메커니즘 반박이므로 verdict=fail로 판정한다.",
  "claims": [
    {
      "doc": "blog:egress_crd-mental-model",
      "cid": "C2",
      "empirical": "refutes-claim",
      "note": "ServiceEntry(TLS)+Gateway(PASSTHROUGH)+VirtualService(tls,sniHosts)+DestinationRule 4종만으로 사이드카 egress를 내부 게이트웨이로 강제 우회시킬 수 있다는 멘탈모델은, 도메인(FQDN)을 registry 규칙대로 정확히 교정한 뒤에도 재현되지 않았다. 근본 원인은 도메인 문제가 아니라, ServiceEntry의 'external' host가 실제로는 mesh registry에 이미 등록된 k8s Service의 ClusterIP로 해석되어 그 Service 전용 per-IP 리스너가 SNI 기반 mesh-gateway 라우팅보다 항상 우선 적용되기 때문임을 LDS 덤프로 직접 확인했다."
    },
    {
      "doc": "gw__guide-egress-gateway-https",
      "cid": "C10",
      "empirical": "refutes-claim",
      "note": "가이드가 설명하는 HTTPS egress 2-hop 구성은 이 클러스터/버전에서 도메인 교정 후에도 재현되지 않음(hop-gw 스케일 0에도 요청 계속 200 = 게이트웨이 미경유). 가이드가 예제로 실제 외부 호스트가 아닌 '클러스터 DNS로 우연히 실 서비스에 해석되는 호스트'를 쓰면 이 메커니즘이 성립하지 않는다는 주의점이 없다면 보강 필요."
    },
    {
      "doc": "gw__report-2026-06-07_ingress-egress",
      "cid": "C2",
      "empirical": "inconclusive",
      "note": "hop-gw가 이번 재실행에서도 트래픽을 전혀 받지 못해(access log 0건, CDS/EDS는 정상 연결되었음에도) L4 access log 포맷 여부 자체를 관측할 수 없었다. 메커니즘이 실제로 작동하는(비-충돌 외부 호스트를 사용하는) 정상 케이스에서 재검증 필요."
    },
    {
      "doc": "gw__src-egress-gateway",
      "cid": "C5",
      "empirical": "refutes-claim",
      "note": "동일 근거: 4종 리소스 조합이 sidecar egress를 물리적으로 hop-gw 경유로 강제한다는 주장이 CDS/EDS가 정상적으로 연결된 상태에서도 반박됨. LDS 레벨의 per-ClusterIP 리스너 우선순위가 원인."
    },
    {
      "doc": "gw__src-egress-gateway",
      "cid": "C11",
      "empirical": "inconclusive",
      "note": "hop-gw의 istio_tcp_connections_opened_total/istio_requests_total 모두 0으로, 'TCP만 보이고 HTTP는 안 보인다'는 차이 자체를 검증할 신호가 없었음(둘 다 0이라 대비 불가). hop-gw가 실제로 트래픽을 받는 시나리오(진짜 외부 호스트 사용)에서 재검증 필요."
    },
    {
      "doc": "gw__src-egress-operations",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "client 사이드카의 proxy-config route에 mock host용 HTTP route가 0개이고 upstream_rq_retry 카운터도 존재하지 않아, 'TLS PASSTHROUGH 경로에서는 VirtualService.http.retries가 컴파일조차 되지 않아 조용히 무시된다'는 운영상 주장은 hop-gw 경유 여부/도메인 교정과 무관하게 이번 재실행에서도 독립적으로 지지됨."
    },
    {
      "doc": "gw__report-2026-06-07_dns-resolution",
      "cid": "C11",
      "empirical": "supports-claim",
      "note": "실제 kubeadm clusterDomain(homelab.local)과 무관하게 Istio 프록시의 내부 registry 도메인은 svc.cluster.local로 고정된다는 사실을 이번 재실행에서 더 강하게 확인함: DR/VS host를 svc.cluster.local로 교정하자 run1의 유령 클러스터(존재하지 않는 CDS 참조)가 실제 HEALTHY 엔드포인트를 가진 정상 클러스터로 바뀌었다(client.proxy-config cluster/endpoints로 직접 확인). VS/DR에서 실제 k8s Service를 가리킬 때는 svc.homelab.local이 아니라 svc.cluster.local을 써야 한다는 규칙이 재확인됨(ServiceEntry로 정의한 host는 literal 그대로 사용하는 것이 맞음). 다만 이 교정만으로는 이 테스트의 E2E 메커니즘 전체가 살아나지는 않았음(별도의 LDS per-IP 리스너 우선순위 이슈가 남아있음) — 이는 이 클레임 자체가 아니라 테스트 설계(mock을 외부 호스트 대역으로 쓴 것)의 한계임."
    }
  ]
}