服务网格 17：入口网关怎样接到内部调用

HTTPS 入口返回 200，内部链路也经过 TLS 吗

读者访问 frontend，frontend 再请求 orders → inventory-v1 + external-stub。入口网关若终止浏览器的传输层安全协议（TLS），获得的是客户端到网关这一段的加密连接；网关转发到 frontend、工作负载间的连接要分别确认。入口 HTTP 200 至多说明本次完整请求得到了响应，不说明内部使用了双向 TLS（mTLS），更不证明有人无法绕开入口直接访问后端。

入口 TLS 终止、Host 和路径匹配、内部调用与可信来源的不同边界

上图把客户端、入口网关、frontend 和内部上游画成四个观察点。TLS 握手里使用的服务器名称指示（SNI）与随后 HTTP Host/:authority 是不同字段：客户端可以在证书匹配的域名上发送另一个 Host。TLS 失败时请求尚未进入应用层路由；证书通过但 Host 或 path 不匹配，是网关路由层的另一类负例；命中路由以后内部服务返回 502/503，还需查看哪一跳报错。不能把这三类失败都记作“网关拒绝”。

匹配、来源地址、身份分别在哪里生效

在网关上声明监听器和 TLS 证书，再把匹配的 Host/path 请求转给 frontend。是否允许某条 Route 附着，须看其 Gateway、命名空间作用域与控制器状态；配置对象提交成功、证书有效和后端可达是三个独立检查。入口终止后若要到后端继续加密，应明确网关到服务端的 TLS 配置和校验对象；如果使用 TLS 透传，网关一般不能直接匹配加密内的 HTTP 路径。工作负载间的 mTLS 还属于另一段连接，不由入口证书自动提供。

跨负载均衡器和代理传递客户端地址时，X-Forwarded-For（XFF）只是 HTTP 头。外部客户端可伪造输入值；Istio 的 numTrustedProxies 必须按网关前可信代理的实际跳数配置，再区分连接对端地址、可信转发链中提取的地址与业务用户身份。即便提取到了一个 IP，也不等于通过了用户认证；只依靠来源 IP 做高权限授权须另证可信路径。更重要的是，若后端存在可直接访问的入口，网关的 Host/path 或鉴权规则不能保护这条绕行路径；应再评估后端网络边界和工作负载授权。

用已有进程先排除错误归因

从 examples/service-mesh/ 分别运行两组已存在的进程对照：

1 2	`bash scripts/run-09.sh bash scripts/run-00.sh`

run-09.sh 在回环地址启动有证书的库存服务：正确名字并信任证书时是正常路径，错误主机名会在客户端证书校验阶段失败；它演示的是客户端到单个 Go 服务的 TLS，不是网关 TLS 终止。run-00.sh 的正常链路会返回库存与 stub 数据；其错误端口、空上游等分支用于识别内部调用失败，不是网关 Host 路由结果。若使用有效证书但请求未知路径，应用可能返回自己的 404；也不可改称 Gateway API 的路由拒绝。两组脚本各自保存原始命令与退出码，不应跨组拼接成一次真实网关请求。

需在隔离环境另做端到端验收：同一入口证书、目标 Host/path、来源地址分别测试正确请求、错误证书／SNI、错误 Host/path 与正确入口但内部故障；保存 TLS 握手、网关路由、代理日志、frontend 与 orders 同一请求 ID 的记录，再在受控网络中尝试直接连后端验证绕过边界。当前没有入口网关或 Kubernetes/Envoy，网关监听器、来源 IP 信任链和内部 mTLS 全部 NOT_RUN；不得给这些待测组合填伪造的响应码。

待验收请求	TLS 握手	网关实际路由	内部调用	直连后端限制
正确 Host/path 与证书	待运行	待运行	待运行	待运行
错误证书或 SNI	待运行	待运行	待运行	待运行
正确证书、错误 Host/path	待运行	待运行	待运行	待运行
内部服务失败或绕过入口	待运行	待运行	待运行	待运行

练习与参考解答

run-09.sh 的错误主机名失败，能证明网关的 Host 匹配生效吗？参考解答：不能。它在直连服务时先发生证书名称验证失败；须让 TLS 名称有效，再分别改变 HTTP Host/path，并以实际网关请求和代理路由日志验证匹配结果。
公网负载均衡器后面有一层可信反向代理，客户端自行加一个 X-Forwarded-For 值；应用可以把最左端 IP 当认证用户吗？参考解答：不能。先按实际可信跳数核对网关提取的客户端地址及连接对端，再另做用户身份认证；被客户端注入的头不是可靠身份凭据。