我目前有一个HTTPS负载均衡器设置,使用443前端,后端和运行状况检查,为单个主机nginx实例提供服务。
通过浏览器直接导航到主机时,页面会正确加载有效的SSL证书。
尝试通过负载均衡器IP访问该站点时,收到502-Server错误消息。我查看了Google日志,并注意到" failed_to_pick_backend"负载均衡器出错。我也注意到它没有通过健康检查。
一些挖掘引导我看到这两个链接:https://cloudplatform.googleblog.com/2015/07/Debugging-Health-Checks-in-Load-Balancing-on-Google-Compute-Engine.html
https://github.com/coreos/bugs/issues/1195
问题#1 - 不确定google-address-manager是否在服务器上运行 (RHEL 7)。我没有在HTTPS中看到HTTPS负载均衡器IP的条目 路线。已安装Google SDK。这是Google提供的图片 如果我在控制台中更新IP地址,它也会更新 主人。如何检查google-address-manager是否正在运行 RHEL7?
[root@server]# ip route ls table local type local scope host
10.212.2.40 dev eth0 proto kernel src 10.212.2.40
127.0.0.0/8 dev lo proto kernel src 127.0.0.1
127.0.0.1 dev lo proto kernel src 127.0.0.1
所有Google服务的输出
[root@server]# systemctl list-unit-files
google-accounts-daemon.service enabled
google-clock-skew-daemon.service enabled
google-instance-setup.service enabled
google-ip-forwarding-daemon.service enabled
google-network-setup.service enabled
google-shutdown-scripts.service enabled
google-startup-scripts.service enabled
问题#2:没有收到200 OK响应。证书有效 和LB和服务器上的相同。当运行卷曲时 应用服务器我收到此回复。
root@server.com curl -I https://app-server.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
思想?
答案 0 :(得分:1)
您应该为运行状况检查服务添加防火墙规则 -
https://cloud.google.com/compute/docs/load-balancing/health-checks#health_check_source_ips_and_firewall_rules并确保您的后端服务侦听负载均衡器ip(最简单的是绑定到Fetching package metadata ...........
Solving package specifications: .
Package plan for installation in environment /home/imakaev/miniconda3:
The following NEW packages will be INSTALLED:
anaconda: custom-py36hbbc8b67_0
The following packages will be UPDATED:
conda: 4.3.31-py36_0 --> 4.4.3-py36_0
anaconda-custo 100% |###################################################################| Time: 0:00:00 15.63 MB/s
conda-4.4.3-py 100% |###################################################################| Time: 0:00:00 48.26 MB/s
) - 这对于内部负载均衡器来说肯定是正确的,不确定HTTPS是否使用外部IP。< / p>
答案 1 :(得分:0)
一些更新和经验教训:
我发现“google-address-manager”现已弃用,取而代之的是正在运行的“google-ip-forward-daemon”。
[root@server ~]# sudo service google-ip-forwarding-daemon status
Redirecting to /bin/systemctl status google-ip-forwarding-daemon.service
google-ip-forwarding-daemon.service - Google Compute Engine IP Forwarding Daemon
Loaded: loaded (/usr/lib/systemd/system/google-ip-forwarding-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2017-12-22 20:45:27 UTC; 17h ago
Main PID: 1150 (google_ip_forwa)
CGroup: /system.slice/google-ip-forwarding-daemon.service
└─1150 /usr/bin/python /usr/bin/google_ip_forwarding_daemon
有一个活动的防火墙规则允许端口443的IP范围为130.211.0.0/22和35.191.0.0/16。目标也已正确设置。
最后,运行状况检查当前使用默认的“/”路径。开发人员在开发过程中在站点前面进行了身份验证。如果我绕过SSL证书错误,我在运行curl时收到了401未经授权的错误。这是我们遇到的问题的根本原因。为了解决这个问题,我们修改了nginx基本身份验证配置以禁用对新路由的身份验证(例如/ health)
一旦更新了nginx配置并且在健康状况检查中将路径更新到新的/健康路线,我们就会收到200个有效的回复。这允许运行状况检查返回健康实例并允许LB通过流量