![Route 53“重定向次数过多”,但从 ELB 访问正常](https://linux22.com/image/775641/Route%2053%E2%80%9C%E9%87%8D%E5%AE%9A%E5%90%91%E6%AC%A1%E6%95%B0%E8%BF%87%E5%A4%9A%E2%80%9D%EF%BC%8C%E4%BD%86%E4%BB%8E%20ELB%20%E8%AE%BF%E9%97%AE%E6%AD%A3%E5%B8%B8.png)
我有一个运行 pgadmin 的 EC2。
端口 80 上有一个目标组指向它。
TG 正在监听端口 443 但 HTTP 因此它可以重定向到端口 80 上的 EC2。(我之前使用的是 443 和 HTTPs,但在网上看到 SSL 终止应该在这里)
有一个 ELB 正在监听 443 并指向 TG。
如果我访问 ELB 的 URL,我可以成功访问pgadmin,尽管浏览器显然显示证书错误,因为该 URL 不是与 ELB 关联的 ACM 证书中的 URL。
我有一个 R53 域,其别名为 ELB,与 ACM 证书匹配,但是当我转到此 URL 时,浏览器中会出现“重定向过多”的情况。
不确定配置哪里可能错误,特别是因为它从 ELB 工作而不是从域工作。
答案1
SSL 终止的典型情况是后端服务器/服务会将其视为:“最终用户通过明文协议连接”,换句话说就是通过普通的 http。
然后,它会通过将用户重定向到 HTTPS 来尝试“解决该安全风险”。
------ --------------- -------------------
| USER | ===> HTTP ==> | Load balancer | ==> HTTP ==> | Redirect to HTTPS |
------ --------------- -------------------
------ ----------------- -------------------
| USER | ===> HTTPS ==> | SSL termination | ==> HTTP ==> | Redirect to HTTPS |
------ ----------------- -------------------
用户发出新请求(他们已经在使用 HTTPS,但重定向就是重定向)但他们将再次被重定向:
------ ----------------- -------------------
| USER | ===> HTTPS ==> | SSL termination | ==> HTTP ==> | Redirect to HTTPS |
------ ----------------- -------------------
然后不断重复。
通常的解决方案是选择性地重新配置 SSL 终止点以向后端服务器发出 HTTPS 请求,并从后端服务器中删除重定向到 HTTPS 功能并将其移动到负载均衡器。
------ -------------------
| USER | ===> HTTP ==> | Load balancer |
------ | Redirect to HTTPS |
-------------------
------ ----------------- ---------
| USER | ===> HTTPS ==> | SSL termination | ==> HTTP(S) ==> | Respond |
------ ----------------- ---------