GCP 负载平衡器上的“FAILED_NOT_VISIBLE”域状态答案

【问题标题】：'FAILED_NOT_VISIBLE' domain status on GCP load balancerGCP 负载平衡器上的“FAILED_NOT_VISIBLE”域状态
【发布时间】：2021-09-25 19:51:37
【问题描述】：

我在 GCP 上配置负载均衡器时遇到问题，我希望有人能指出正确的方向来解决它。

我在 GCP 中的一个实例上运行 Web 服务器，我想通过 HTTPS 访问来保护它。为此，我遵循了此链接https://cloud.google.com/iap/docs/load-balancer-howto 上提供的示例。所以，我保留了域名、静态 IP 地址和 SSL 证书；并按照链接配置负载均衡器。

该实例位于 HTTPS 外部负载平衡器后面，该负载平衡器应通过 HTTPS 与客户端通信，并通过 HTTP 与后端服务通信。
负载均衡器前端指向静态IP地址，正式预留，443端口开放，SSL证书到位。
负载平衡器的后端是一项服务，其中包括运行 Web 服务的实例。

问题：安全连接永远不会成功！！我检查了证书详细信息，页面显示“域状态：FAILED_NOT_VISIBLE”和“状态：PROVISIONING”。因此，我查阅了页面“故障排除 SSL 证书”https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting?&_ga=2.170344355.-201250651.1616078055#domain-status 并尝试检查所有可能性，但均未成功。

我为负载均衡器配置了一个额外的前端以允许 HTTP，然后我可以使用静态 IP 地址和域名通过负载均衡器连接到 Web 服务器，这表明问题仅在 SSL证书。
我尝试创建新证书并替换旧证书，但没有成功。
尝试连接负载平衡器的静态 IP 地址时，Web 浏览器返回“PR_END_OF_FILE_ERROR”。

如果你能提供帮助，那就太好了。

++++++更新——关注@JohnHanley 评论++++++++
从GCP获取的DNS信息如下：

$ gcloud compute addresses list
NAME              ADDRESS/RANGE   TYPE      PURPOSE  NETWORK  REGION  SUBNET  STATUS
followup-ipv4     34.120.aaa.bbb  EXTERNAL                                    IN_USE

$ gcloud dns managed-zones list
NAME             DNS_NAME          DESCRIPTION  VISIBILITY
followup-com     followup.com.                  public

$ gcloud dns record-sets list --zone=followup-com
NAME                  TYPE   TTL    DATA
followup.com.         A      300    34.120.aaa.bbb
followup.com.         NS     21600  ns-cloud-d1.googledomains.com.,ns-cloud-d2.googledomains.com.,ns-cloud-d3.googledomains.com.,ns-cloud-d4.googledomains.com.
followup.com.         SOA    21600  ns-cloud-d1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
www.followup.com.     CNAME  300    followup.com.
$ gcloud compute forwarding-rules list
NAME                       REGION  IP_ADDRESS      IP_PROTOCOL  TARGET
followup-frontend                  34.120.aaa.bbb  TCP          followup-lb-target-proxy
followup-http-frontend             34.120.aaa.bbb  TCP          followup-lb-target-proxy-2
$ gcloud compute forwarding-rules describe followup-frontend
For the following forwarding rule:
 - [followup-frontend]
choose a region or global:
 [1] global
 [2] region: asia-east1
 [3] region: asia-east2
 [4] region: asia-northeast1
 [5] region: asia-northeast2
 [6] region: asia-northeast3
 [7] region: asia-south1
 [8] region: asia-south2
 [9] region: asia-southeast1
 [10] region: asia-southeast2
 [11] region: australia-southeast1
 [12] region: australia-southeast2
 [13] region: europe-central2
 [14] region: europe-north1
 [15] region: europe-west1
 [16] region: europe-west2
 [17] region: europe-west3
 [18] region: europe-west4
 [19] region: europe-west6
 [20] region: northamerica-northeast1
 [21] region: southamerica-east1
 [22] region: us-central1
 [23] region: us-east1
 [24] region: us-east4
 [25] region: us-west1
 [26] region: us-west2
 [27] region: us-west3
 [28] region: us-west4
Please enter your numeric choice:  1

IPAddress: 34.120.aaa.bbb
IPProtocol: TCP
creationTimestamp: '2021-06-04T20:06:37.991-07:00'
description: ''
fingerprint: RBZP24MTKcQ=
id: '2154259932761248978'
kind: compute#forwardingRule
labelFingerprint: 42WmSpB8rSM=
loadBalancingScheme: EXTERNAL
name: followup-frontend
networkTier: PREMIUM
portRange: 443-443
selfLink: https://www.googleapis.com/compute/v1/projects/projectID/global/forwardingRules/followup-frontend
target: https://www.googleapis.com/compute/v1/projects/projectID/global/targetHttpsProxies/followup-lb-target-proxy

【问题讨论】：

您域的权威名称服务器没有指向 HTTP(S) 负载均衡器的正确 DNS 资源记录。如果您需要有关该配置的帮助，请使用您的域名和为（指向）负载均衡器配置的每个资源记录编辑您的问题。否则，有一些互联网工具可以帮助您调试此问题，例如mxtoolbox.com/DnsLookup.aspx
感谢@JohnHanley 的评论。我在 GCP 中保留了 DNS 记录，并且配置适用于 HTTP（非 HTTPS）转发规则！因此，如果我将网络浏览器指向 HTTP 链接上的网络服务器，它就会成功连接！ BTW，我查了你说的那个工具，没能把域名解析成IP！？虽然网络浏览器（在连接到不同网络的不同设备上）可以工作！！！
如果您的域是 followup.com，您的 DNS 服务器位于 Cloudflare 而不是 Google。您需要在 Cloudflare 设置您的 A 和 CNAME 记录。

标签： google-cloud-platform load-balancing

【解决方案1】：

深入研究 GCP 文档（特别是 this），我发现我错过了按照 GCP 中的建议将一条信息（pki.goog 和letsencrypt.org 的CAA 条目）添加到项目的DNS 记录中。 BOLD 中添加的有效 DNS 记录如下：

$ gcloud dns 记录集列表 --zone=followup-com
名称类型 TTL 数据
跟进网站。 A 300 34.120.aaa.bbb
followup.com。 CAA 300 0 问题“pki.goog”，0 问题“letsencrypt.org”
跟进网站。 NS 21600 ns-cloud-d1.googledomains.com.,ns-cloud-d2.googledomains.com.,ns-cloud-d3.googledomains.com.,ns-cloud-d4.googledomains.com.
跟进网站。 SOA 21600 ns-cloud-d1.googledomains.com。 cloud-dns-hostmaster.google.com。 1 21600 3600 259200 300
www.followup.com。 CNAME 300 followup.com。

【讨论】：

1) 之前的 CAA 记录有什么问题？ 2) 请提供指向您所指文档的链接。
没有 CAA 记录不会阻止 Let's Encrypt 颁发证书。您的问题没有显示 CAA 记录，因此您对报告的问题的回答不正确。如果 Let's Encrypt 是发行机构，您的 CAA 记录是正确的，但这不会解决您的问题。要么时间流逝并发生传播，要么您进行了实际上是解决方案的其他更改。
@JohnHanley 1) DNS 记录没有 CAA 条目（请检查问题文本，特别是命令 $ gcloud dns record-sets list --zone=followup-com 的输出） . 2）我在答案中放置了文档的链接。 3) 我之前提到的文档指出，在您的 DNS 软件中，我们建议您明确授权您希望允许的 CA 颁发您的 Google 管理的证书。虽然并非在所有情况下都需要，但在某些情况下这是必要的。 4) 我陈述了我所做的更改，我不接受你暗示我隐瞒了什么。
@JohnHanley 我在负载均衡器的配置上工作了 1 周，但没有运气。然后我读到 CAA 记录是必要的，所以我添加了它们并创建了一个新证书，而不是旧证书，它不起作用。新证书的状态会在几小时内变为活动状态。
这种效果是巧合，不是解决方案。 CAA 记录不是必需的，它们不存在也不会妨碍颁发证书。您的答案不正确，会误导未来寻求解决方案的读者。