我们的系统依赖一个第三方的服务,该服务是通过IP限制访问权限的。出于安全考虑,我们的系统会校验证书,因此我们采用Nginx反向代理去访问该服务。该服务迁移到cloud上之后,我们系统出现了问题。 Nginx的配置文件如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
http { upstream backend.example.com { server backend1.example.com:443; } server { listen 80; server_name www.example.com; location /upstream { proxy_pass https://backend.example.com; proxy_ssl_certificate /etc/nginx/client.pem; proxy_ssl_certificate_key /etc/nginx/client.key; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt; proxy_ssl_verify on; proxy_ssl_verify_depth 2; } } } |
Debug 在出现线上问题的时候,第一时间检查了配置文件的改动记录 ⇒ 配置文件没有改到。 接着检查了,证书是否过期⇒没有过期。 通过域名curl请求 ⇒ 第三方服务正常,证书正确。 在我们没有任何改动的情况下,第三方服务也是单纯地做了迁移,然后就挂了。 思考了很久之后,Nginx没有任何改动,那么出问题的一定不是我们。那么出问题一定是第三方,最直接的方式是联系第三方提供商,联系渠道很繁琐,时间成本也会很高。为了快速修复问题,我们决定盲调Bug。 尝试解决 第一次尝试,已知curl请求一切正常。尝试着将upstream干掉,直接写道proxy_path中。依旧是失败,错误日志中出现了”https://1.1.1.1:443 TLS handshake failed”。推断,proxy_path会将域名转换成ip。 第二次尝试,尝试检查curl ip来访问服务。失败。推断,IP和域名指向了两个不同的服务。到这里算是找到root cause了。 解决思路:反向代理时候,通过域名访问而不是IP访问。 查询文档,发现可以使用配置项:proxy_ssl_server_name,该配置项默认值是off,需要将一些内容写到配置文件中:
1 |
proxy_ssl_server_name on; |
第三次尝试,将proxy_ssl_server_name on写入到配置文件中。成功。 什么是server_name 服务器名称指示(Server Name Indication, SNI)是对TLS协议的扩展。在握手过程开始时,通过该协议,客户端指示其尝试连接的主机名。该协议允许服务器上的同一个IP和TCP端口拥有多个证书,因此允许同一个IP地址为多个HTTPS网站提供服务,且无需所有网站使用相同的证书。 from:https://www.realks.com/2021/03/07/nginx-proxy-ssl-server-name/
View Details