一次外網權限開通的反思

全封閉内網通路上行權限

2017年8月3日

9:30

一次權限開通引發的思考。

    環境：公司用的 nginx + Tomcat高可用負載均衡，nginx有連結外網的權限，Tomcat所有伺服器隻能在内網通路。

    需求： Tomcat伺服器現在要連結上海銀行給的一個https的公網位址 ip + port 。

   動手前個人猜想： 伺服器調用銀行位址，隻要伺服器能通路外網不就能通路到這個位址了？是以我要讓伺服器上網。  1.直接讓網絡工程師在網絡裝置上開通權限。 2。我的nginx可以上網我可以在這裡做代理，讓其他伺服器上網。

    犯下的罪：1. 沒有考慮到要用支援https的代理軟體. 隻想着能上網就行了。    2. 伺服器能上網不代表能通路到銀行的位址。後面由講到。

     初步計劃： nginx正向代理，nginx代理做好後測試發現有的網站能通路，有的網站不能通路。後來才知道，nginx正向代理隻支援 http，而不支援 https 。缺乏考慮。

     反思： 對于通路位址厘清楚是 http 還是 https。做代理前先了解 代理軟體是否支援你所需要的功能。

   二次崛起嘗試計劃： 當了解到squid代理支援 https，二話不說就又做了 squid的正向标準緩存代理。後面測試 https http代理上網都可以成功。 但是唯獨銀行給的位址不能用。原因公司伺服器公網ip沒有加入銀行白名單。

      反思： 銀行一般都有白名單，要通路銀行給的位址。一定要先，讓銀行把你的伺服器公網IP加入銀行白名單。 做事先考慮外部影響因素。因為内部因素都是公司自己内部的問題。協商解決很快，和其他公司打交道，開權限，流程複雜，時間很長。如果業務要緊急上線，加一個白名單要等1-3天，在你這浪費了時間。相信上司從此不會對你有好印象的。

                                                     是萬事俱備，還是又跳深坑？

過了2天，銀行才把伺服器公網IP給到我們，那天我晚上11點準備睡覺。上司打來電話：“上行接口位址已經給我們了，但是現在不能通路，是不是代理出問題了？”我：“不會吧，代理我測過呀，外網都能通路呀，百度，淘寶，jd我之前都測過的呀！” 我這時就有點虛了，不是Tomcat伺服器外網能通路，上行的接口位址一定能通路嗎？現在怎麼回事？

    排查問題開始：

          1. 在可以上網的nginx上看看 上行位址 ，假如說是 1.1.1.1:8123, 能不能通路。 方法 telnet 或  curl  -k  ：跳過ssl驗證。   結果是可以的。---》上行權限已經開通，跟上行沒關系了。内部排查開始。

          2.在tomcat伺服器上同樣方法通路，傳回 proxy 403錯誤。和當時猜想結果差别太大，一臉大寫懵B。 -----》通路 jd 淘寶 百度，都正常。唯獨上行 接口IP,不行。代理可能有問題。

代理的日志裡是這樣的報錯： TCP_DENIED/403 3664 CONNECT  1.1.1.1:8123  - NONE/- text/html

然後嘗試很多種辦法，到了夜裡2點左右還沒解決。種種原因。隻能等第二天繼續解決，如果。

        第二天因為可能要上線，是以沒有時間給我解決問題。在做代理之前我給上司提了兩套方案。做代理是第一套，因為時間問題，放棄。 直接實施第二套方案，讓網絡人員直接在網絡上開通到上行接口通路權限。（這裡tomcat伺服器資料出去的公網位址一定是要先讓銀行加入到白名單才行）

反思： 考慮問題不夠全面，先是外部因素沒有解決，導緻後面出現問題，再是選擇代理應用時，考慮太少，感覺隻要是正向代理都能上網，肯定都支援http https兩種呀。其實太自信，現實不是這樣。  做事一定要留一手，這套方法不行，我們應該怎麼辦？