一, 背景
近来在一次混合云架构中 API 接口暴露由于种种原因, 遇到点波折, 记录一下.
客户为金融企业对 SLA 要求及数据安全性很高, 有限于考虑到业务的高可用性, 采用混合云部署, 业务流量入口为阿里金融云, 前端可以添加安全设备 WAF/CDN / 高防 IP 等, 之后 Cname 到统一入口 SLB 负载均衡上, 后端采用虚拟服务器组, 组内 ECS 部署在同 Region 的不同 Zone, 保障跨 Zone 的靠可用性, 考虑到数据的安全性将数据持续化在 IDC 侧, 阿里云与 IDC 通过云上部署深信服设备与 IDC 侧 Cisco 设备通过 Ipsec *** 互联 (考虑到稳定性目前已经实施专线互通), 后端 App-Server 与 DB-Server 部署在 IDC, 可参考下图:
1.1 客户需求:
客户之前由于同域名同端口下有不少业务, 因此采用 Nginx 反向代理后端 App 模式, HTTPS 方式, 将证书放在前端 web-Server 侧即可, 或可以使用 SLB 的七层模式将证书放置在 SLB 上. 但是此次部署的为一个后端的 App 为 HTTPS 业务, 是带有证书, 需要将接口暴露到公网.
1.2 问题痛点:
经过测试客户在 IDC 侧 App-server 部署的接口为 HTTPS 模式, Nginx 采用 http 方式反代 502 证书不信任, 无法反向代理成功, 想到利用 HTTPS 方式反代, 或者联系客户修改后端 API 接口为 HTTP 方式, 但是金融云 Web-Server 也需要 App-Server 的证书, 客户反馈其他供应商部署短时间无法获取到, 需要先忽略证书解决问题.
1.3 架构剖析:
此时修改 IDC 侧为 HTTP 方式无法进行, 由于证书拿不到, 金融云 Web-Server 侧利用 HTTPS 方式反向也无法进行, 一度陷入僵局, 继续沟通得知改接口正式环境已经在 IDC 侧部署完毕, 但测试新功能需要暴露公网测试接口, 那为何不再 IDC 侧有公网 IP 的服务器进行代理, 或者防火墙 DNAT 进来, 实现需求呢, 客户反馈 IDC 侧 IP 规划已经没有, 还需要协助从金融云暴漏测试接口.
1.4 解决方案:
既然 Nginx 反代不行, SLB 后端也无法直接添加 IDC 侧的 App 服务器, 那就利用 Web-server 利用 iptables 进行端口转发, 配置 DNAT 和 SNAT 直接将流量抛过去, 想到这里开始着手测试实施.
二, 技术实现
具体的操作部署由于涉及到系统 / 网络 / 中间件 / 及阿里云产品相关操作, 在此就不一样截图列举, 简单列下实施步骤及注意要点.
2.1 架构图
2.2 网络互通
首选需要在金融云深信服与 IDC 侧思科防火墙方向对应端口及 IP, 实现网络互通, 需要注意在阿里云需要配置到 IDC 侧的路由, Web-server 与 App-server 可以相关正常内网通讯.
2.3 域名及 SLB
由于是测试域名前端暂时未添加 WAF / 高防 IP 等防护设备, 将域名解析 A 记录解析至 SLB 公网地址, SLB 配置虚拟服务器组, 组内添加 Web-Server, 此时监听端口为 Dnat 端口.
2.4 IPTABLES 转发
根据 SLB 配置的端口转发, 配置响应规则, 例如:
- -A PREROUTING -d 10.69.xx.xx/32 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.19.xx.xx:8080
- -A POSTROUTING -d 172.19.xx.xx/32 -p tcp -m tcp --dport 8080 -j MASQUERADE
配置完成可以从公网利用 postman 测试接口.
三, 反思
由于受限与种种业务原因, 这边列举下具体的可实施方案, 可供以后参考:
如果可能可直接在 IDC 侧有公网服务器进行反代暴露接口
在 IDC 侧 Cisco 设备 Dnat 映射业务端口进行暴露接口
在阿里金融云如果有证书可以采用 HTTPS 反代暴露接口
更改后端 App-server 为 HTTP 方式, 可以在阿里云侧采用 HTTP 方式反代暴露接口
在 Web-server 采用 iptables 转发进行 HTTPS 方式暴露接口.
来源: https://juejin.im/post/5c7d610751882564965eedb2