一、背景
近來在一次混合雲架構中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方式暴露介面。