記一次混合雲API發佈的反思

1、背景

近來在一次混合雲架構中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、技術實現

具體的操做部署因爲涉及到系統/網絡/中間件/及阿里雲產品相關操做，在此就不同截圖列舉，簡單列下實施步驟及注意要點。

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測試接口。

3、反思

因爲受限與種種業務緣由，這邊列舉下具體的可實施方案，可供之後參考：

• 若是可能可直接在IDC側有公網服務器進行反代暴露接口
• 在IDC側Cisco 設備Dnat映射業務端口進行暴露接口
• 在阿里金融雲若是有證書能夠採用HTTPS反代暴露接口
• 更改後端APP-server爲HTTP方式，能夠在阿里雲側採用HTTP方式反代暴露接口
• 在WEB-server採用iptables 轉發進行HTTPS方式暴露接口。