内部 https 负载均衡器 GCP 后面的 Nifi 实例答案

【问题标题】：Nifi instance behind the internal https load balancer GCP内部 https 负载均衡器 GCP 后面的 Nifi 实例
【发布时间】：2021-01-04 08:53:06
【问题描述】：

我有一个正在运行的 nifi 实例

 https://localhost:9443/nifi
 https://delta:9443/nifi

实例仍在本地运行。我想在 nifi 实例前面有一个内部 https 负载均衡器。我读过我们可以在 nifi-cert 上添加负载均衡器的 SAN ip 地址。我仍然对 DNS 和 SAN 地址感到困惑。我有一个 https 负载均衡器的自签名证书，并且负载均衡器也有一个 DNS 条目。现在，当我创建一个独立的 nifi CA 时，我是否必须将负载均衡器的 DNS 指定为

tls-toolkit.sh standalone -n 'loadbalancer DNS' -C 'CN=username,OU=NIFI' --subjectAlternativeNames 'lb-ip-address'

还是我错过了什么大事？？

【问题讨论】：

标签： apache-nifi google-cloud-load-balancer

【解决方案1】：

我不确定 SAN 标志是否会接受除域名和没有 IP 地址以外的其他内容，但根据 this 它可能会起作用。

-n 标志应填充与您的前端（负载均衡器）关联的域名。

【讨论】：

我已经厌倦了你在链接中提到的同样的事情。不知何故，码头服务器没有绑定 DNS 名称。我已检查 DNS 名称是否也解析为负载均衡器 ip
您可以先使用内部 HTTP 再试一次，如果可行，添加或尝试使用内部 HTTP(S) 负载平衡器。另外，您可能会查看它是否仅针对本地主机设置，如果是，您应该将其从 127.0.0.1 更改为 0.0.0.0 link。
我发现由于负载均衡器ip不在linux etc/hosts文件中，所以jetty服务器不会绑定ip地址。所以我为独立的 nifi 创建了客户端证书，并将负载均衡器从 https 更改为网络负载均衡器。所以现在 TLS 终止将发生在 nifi
您似乎找到了解决问题的方法。对吗？
是的，最终当我们在云上使用 https 负载均衡器时，由于 TLS 终止，请求头与来自客户端的请求头不同。由于我有客户端证书而不是代理证书，Nifi 不会接受它。所以不得不将负载均衡器从 https 更改为 tcp