时间戳

首页 > 解决方案 > Google Cloud TCP 外部负载平衡器和 TLS 未自签名

ssl - Google Cloud TCP 外部负载平衡器和 TLS 未自签名

问题描述

是否可以使用公共证书直接公开 L4 负载均衡器后面的服务器？

该服务器位于 Kubernetes pod 内。它前面有一个 TCP 负载均衡器服务，它创建外部 L4 LB。

我的问题是 TLS 流量没有到达 pod 内的容器。因此，如果您成功使用了类似的配置，我很想知道。

更新

我没有提到流量是GRPC。

这是我所做的：我有一个域和相应的官方证书。我想保护 grpc 连接。

我尝试了两种方法：

在这种情况下，我在客户端收到这样的消息：

D0610 14:38:46.246248584 32401 security_handshaker.cc:176] 安全握手失败：{"created":"@1591792726.246234613","description":"握手失败","file":"../deps/grpc/src/核心/lib/security/transport/security_handshaker.cc","file_line":291,"tsi_code":10,"tsi_error":"TSI_PROTOCOL_FAILURE"}

我看到一些与wireshark的TLS交换，但没有登录esp。

错误：1408F10B：SSL 例程：ssl3_get_record：错误的版本号

在google ESP 文档中，我看到我必须证明该域属于我并上传证书（但在哪里）？

更新 2

截至今天，我没有看到任何证据表明它是可行的。

IMO，主要问题是L4具有与证书域名对应的IP。因此，Pod 没有正确的 IP 来证明他们可以使用证书，因此他们对根的请求被拒绝（我没有证据证明这一点，因为我无法从 ESP 中的 nginx 获取调试信息。我已经看到了使用纯 GRPC 服务器解决方案请求）。

标签： sslgoogle-cloud-platformload-balancinggoogle-kubernetes-enginegke-networking

解决方案

问题出在 TLS 交换中。

通过在 ESP 中安装证书，它可以在 Web 浏览器中正常工作，并且证书被指示有效，而对于 GRPC 客户端，TLS 握手失败。添加额外的跟踪信息有帮助。

通过检查我的证书（不是自签名但附加到我的域），我发现它提供了一个中间证书。我将它与域证书（在同一个 crt 文件中）一起安装，然后它就可以工作了。

我不知道它为什么会这样，但可能是由于 grpc 客户端库中的 root_cert 文件太旧了。

顺便说一下，对于域证书，证书的 CN 和 subjectAltName 没有具体要求。没有它它也能工作。所以它必须只适用于我在其他地方看到的自签名证书。

我还有一个问题扰乱了我的任务：注意不要将 L4 负载均衡器的服务端口命名为内部带有“http2”。我有一些副作用，因此导致另一个部署失败。其实做https的时候，不要把http2放在名字里。

无论如何，它现在正在工作并回答赏金请求。感谢所有试图提供帮助的人:)

推荐阅读