無論是產品類還是方案類，在實際項目中大部分都是部署在Linux伺服器中，而再基於Nginx進行代理和負載均衡、域名解析等，最終實現外部訪問和使用。而在實際的部署和使用過程中，出於安全性考慮，都會進行內外網交互，進行多層安全加固。而作為中間件類產品，IDM、ESB等產品往往需要內外網的不同訪問方式，從而滿足不同場景。
在最近的一個集成底座（IDM+MDM+ESB）項目中，由於IDM提供的統一認證，而考慮到外部訪問以及內部系統的認證集成，所以需要集成底座提供內、外網兩種訪問入口，並且保證相互的訪問不會互相衝突。
總體說明
出於安全性考慮，部署在內網的集成底座不能直接釋放到外網，所以需要用Nginx代理的方式將集成底座的訪問入口代理到外網，從而實現從外網訪問各個產品，同時需要保證內網的各個產品、接口都是可用的，從而保證內網環境下業務系統與集成底座進行集成、認證的需要。
1.業務需求
1.保證集成底座在內網環境下是可用的，包括產品的訪問、各個產品功能模塊，以及產品預置、通過ESB開發的各個服務接口都是可用的；
2.集成底座需要提供外網的訪問入口，能夠通過IP或域名的方式進行集成底座產品訪問，以及產品內相關功能的正常使用；
3.保證業務系統可以和IDM平台進行CAS、OAuth認證的配置和接口調用，包括外網地址跳轉，內網認證、接口調用等。
2.配置方式
基於Nginx實現內外網的代理訪問，由於集成底座平台本身採用雲平台的部署方案，也是使用Nginx代理實現的內網虛擬IP訪問各個平台，並且通過Nginx分別代理開發、測試、生產各個不同埠的訪問，該Nginx定為內網Nginx。
考慮到外網訪問的需要，在伺服器DMZ區部署一台外網伺服器，解析外網IP，在伺服器上部署Nginx，通過Ngixn代理的方式代理集成底座內網的訪問地址，改Nginx定為外網Nginx。
3.問題分析
在通過內、外網Nginx代理後，內網由於都是走的內網IP，所以無論是產品訪問和功能使用都不存在問題，包括和業務系統對接時的內網接口調用都是可以的。但是由於外網訪問的相關配置和Nginx代理問題，導致外網訪問時存在問題，問題如下：
1.外網Nginx代理之後，通過OAuth進行統一認證的系統通過外網IP訪問時，在跳轉統一認證登錄頁面時顯示外網IP + 內網埠；
2.外網Nginx代理之後，通過CAS認證的系統在通過外網域名訪問時跳轉到了集成底座內網的CAS地址上；
3.通過外網IP訪問IDM平台後，在第一次登錄進行密碼初始化修改時，會通過到內網IP打開修改密碼頁面。
網絡架構
針對集成底座進行內外網代理時出現的內外網IP交叉跳轉的問題，進行了問題定位與排查，由於集成底座內網訪問交互是沒問題，所以首先考慮從網絡層面進行處理，所以在內部進行單機環境環境驗證，並且儘量模擬項目的網絡環境。
1.單機模式
由於本地資源有限，無法模擬現場環境基於雲平台、DMZ數據隔離以及網絡防火牆的處理，所以採用單機進行產品部署，同時Nginx也是採用內外網兩個Nginx進行處理，從而復現項目上的問題。
2.雲平台模式
集成底座現場環境採用雲平台的部署方案，內部部署K8S集群和相關產品，通過內網Nginx對外提供統一的訪問入口，並在Nginx中配置不同的埠從而實現開發、測試、生產環境的隔離訪問；再通過外網Nginx代理內網Nginx，從而提供外網的訪問入口。
訪問時內網通過VPN接入（或者在本地區域網訪問），通過內網IP和埠直接訪問內網Nginx，從而訪問各個產品；外網訪問時通過外網IP和埠先訪問到外網Nginx，再指向內網Nginx進行內部集群和產品的訪問。
3.伺服器配置
本地伺服器：
1.準備兩台伺服器，具備內網和外網IP；
2.兩台伺服器分別部署Linux和Window系統（需要安裝瀏覽器進行訪問）；
3.Linux系統下部署idm（單機部署）、資料庫和Nginx（內網）；
4.Window系統下部署Nginx（外網）以及瀏覽器，主要通過這裡進行訪問測試；
5.Linux：只考慮內網IP，IP：10.0.0.9，產品埠 3030，內網Nginx代理埠8007；
6.Window：只考慮外網IP，101.101.81.156，外網Nginx代理埠8008；
7.10.0.0.9和101.101.81.156兩台伺服器已經完成了內網的互通，可以通過內網IP相互訪問，並且相互開放了防火牆，不存在埠限制。
雲平台：
雲平台採用標準的5台伺服器高可用配置，在worker1和worker2上部署Nginx集群作為統一的訪問入口（內網Nginx集群），具體配置參見K8S集群高可用配置文檔，這裡不做過多說明。
單機驗證
在本地進行單機部署，參考現場環境的Nginx、產品進行相關文件配置，模擬並復現現場環境中出現的訪問時內外網相互交叉的問題，並通過Fiddle、Wireshake等工具進行抓包分析，分析具體原因並進行修復。
1.產品配置
產品主要需要配置IDM的相關文件，包括web.xml、hotweb.properties，以及idm_server和server.xml文件，CAS以及資料庫、Redis等連接信息均採用內網IP進行配置。
> > > >web.xml
配置casServerLogoutUrl參數，配置為內網CAS的登出地址：
配置CAS認證信息，CAS相關地址配置為內網IP（10.0.0.9:3030/cas），server地址配置為IDM的內網IP（10.0.0.9:3030）。
> > > >hotweb.properties
主要配置資料庫和Redis：均配置內網地址，由於在同一台伺服器，資料庫直接只用localhost:3306，Redis配置為10.0.0.9:6379（Redis配置文件限制）：
> > > >server.xml
server.xml主要時在Host中添加Value配置，remoteIpHeader、portHeader、protocolHeader、protocolHeaderHttpsValue參數會和Nginx的配置進行關聯。
2.nginx配置
Nginx配置分為內網Nginx配置和外網Nginx配置，內網Nginx主要處理IDM產品的訪問，模擬現場環境的內網Nginx，將產品的3030埠代理成8007埠；外網Nginx用於驗證外部的訪問，將內網Nginx代理到外網，並代理成8008埠。
> > > >內網Ngixn
內網Nginx的listen為8007埠，proxy_pass為http://10.0.0.9:3030，直接指向內網的IDM產品，並且代理埠為8007。
在101.101.81.156伺服器上通過瀏覽器直接訪問http://10.0.0.9:8007（兩台伺服器已經完成了內網互通），測試結果如下：
根據測試，通過內網Nginx進行訪問、密碼修改、頁面跳轉等，內網IP、埠均為Nginx代理的IP和埠，不會出現內外網、IP埠相互混合的問題。
> > > >外網Nginx
外網Nginx的listen為8008埠，proxy_pass為http://10.0.0.9:8007，指向內網的Nginx，以及Nginx的代理埠8007。
在101.101.81.156伺服器上通過瀏覽器直接訪問http://101.101.81.156:8008，測試結果如下：
在登錄時，攔截到CAS頁面時出現外網IP+內網Nginx埠的問題，導致訪問出錯。
3.抓包分析
為了分析訪問時埠異常的問題，通過Fiddle和Wireshake抓包分析，分析前後端的返回信息，從而進一步定位問題。
> > > >Fiddle
1.先通過外網地址訪問，通過8008埠訪問到內網，請求到IDM；
2.IDM根據訪問信息，跳轉到IDM的index?Login，服務端根據CAS認證進行攔截，攔截到CAS認證地址，ip:8008/cas/login；
3.發起CAS對CAS的請求時，地址顯示依然時8008埠，是正常的。
通過Fiddle抓包測試，通過外網訪問時，前端請求均為8008埠，並且服務端返回到前端的信息和跳轉路徑均為8008埠，並未出現8007埠的異常。
> > > >Wireshake
1.先通過外網地址訪問，通過8008埠訪問到內網，請求到IDM；
2.IDM響應，返回跳轉路徑：index?Login；
3.跳轉index?Login，再次發起請求，還是基於外網IP和8008埠訪問；
4.服務端響應，服務端返回時將8008埠改成了8007埠。
經過Wareshake抓包測試，發現是由於CAS認證攔截跳轉時，通過302永久重定向，拼接訪問路徑時在外網IP的基礎上拼接了內網Nginx埠，從而導致地址訪問異常。
4.調整驗證
根據後端返回的信息，發現是由於服務端處理埠的問題，所以要進行埠處理，但根據Wireshake抓包測試，發現是由於服務端拼接了內網Nginx埠，而通過查找Nginx的相關配置，嘗試通過proxy_redirect的方式實現外網Nginx的重定向，即內網返回response時，外網Nginx將ip和埠信息進行替換，替換為外網ip和埠。如圖所示：
調整之後進行訪問測試：
登錄頁和登錄之後均可以正常訪問，相關IP和埠也均為外網IP和埠，功能正常，測試通過。
集群驗證
在內部測試通過後需要在現場環境，即雲平台環境進行測試，由於雲平台採用K8S部署，K8S內部還存在ingress-nginx，所以也要進一步進行測試，特別是現場環境涉及多個產品以及內外網的交叉訪問，同時也會涉及到到其他系統對於接口的調用，所以會更加複雜。
1.IDM配置
web.xml：
server.xml：
2.Nginx配置
Nginx配置也是分為內網Nginx和外網Nginx，其中內網Nginx是在進行K8S集群部署時配置的，主要時通過Nginx配置vip，然後代理訪問K8S集群內部的開發、測試、生產等不同的環境。
> > > >內網Nginx
內網Nginx通過指定82埠為生產環境埠，通過proxy_pass配置指向K8S集群的ingress-nginx地址，再基於K8S的集群管理訪問到容器內的各個產品。
> > > >外網Nginx
外網Nginx直接配置外網訪問的代理埠8008，location中通過proxy_pass指向內網Nginx下的82埠，並通過proxy_redirect進行重定向，將內網的82埠重定向成外網的8008。
注意：雲平台模式和單據模式有一定不同，單據模式proxy_redirect時是將外網IP:內網Port重定向成外網IP:外網Port，但云平台需要內網IP:內網Port重定向成外網IP:外網Port，這個主要是由於內網的ingress-nginx做了處理，返回外網時是內網IP:內網Port。
3.抓包分析
由於現場環境都是部署再Linux伺服器上，而Linux伺服器是無法通過Wireshake進行抓包分析，所以採用Tcpdump進行抓包，並生成對應的文件，再將文件導入Wireshake進行分析。
tcpdump命令：tcpdump -c 5000 -i ens33 host xxx.xx.xx.69 and port 22 -w /opt/tcpdump.cap；
解釋：tcpdump -c 抓抓取數據包量 -i 網卡 host IP位址and port 埠 -w 生成的文件路徑。
抓包結果如下（Nginx調整前）：
1.先通過外網地址訪問，通過8008埠訪問到內網，請求到IDM；
2.IDM響應，返回跳轉路徑：index?Login，顯示的地址和埠依然是外網信息；
3.跳轉index?Login，再次發起請求，還是基於外網IP和8008埠訪問；
4.服務端響應，服務端返回時直接返回了內網IP和內網埠（這裡和單機不一一致，通過定位確認是ingress進行了處理）。
5.再次發起請求，雖然能成功訪問，但是直接跳轉到了內網IP和埠上。
根據抓包分析以及在內部單機測試的結果，調整外網Nginx的配置文件，添加proxy_redirect的配置，將內網的IP和埠重定向到外網的IP和埠，即可正常訪問，並且內外網訪問時也不會出現衝突，相關的接口調用也正常，測試通過。
分析總結
本次工作時第一次在項目中碰到如此複雜的網絡處理，之前在其他項目中，通過Nginx代理或者配置相關的域名都能很快解決問題，但是本次花費大量時間進行問題定位，不過收穫也是比較大的，對於Fiddle、Wireshake、tcpdump都更加熟悉了，後續也能更加熟練地使用，對於集成底座在實際項目中內網的交互方式也更加清晰。
1.問題總結
伺服器和網絡問題一直都是實際項目工作中的薄弱項，在項目中經常會遇到類似的內外網交互、跳轉、不同網絡下的各業務系統接口調用、數據同步分發等場景，所以更多地掌握伺服器和網絡相關知識是非常有必要的，在項目中遇到相關問題也可以快速定位解決，避免因為這些外部因素影響項目的交付效果。
2.技術提升
本次定位處理過程不僅解決了項目上的問題，更重要的是對於相關的工具、網絡等有了更深的認知，特別是Fiddle、Wireshake、tcpdump等，這是非常重要的，在後續的項目中如果遇到類似的問題，也能有更好的定位方案。
1.Fiddle：屬於客戶端抓包工具，可以直接對瀏覽器訪問進行攔截和抓取，獲取瀏覽器請求的相關信息，和瀏覽器開發模式獲取網絡信息類似，但Fiddle或更加直觀和全面，不會被，出現網絡等相關問題時，先考慮用Fiddle抓包查看；
2.Wireshake：屬於服務端抓包工具，能夠抓取服務端的數據包，對於Nginx反覆交互的環境，由於返回到瀏覽器的數據包是經過了Nginx的，所以Fiddle抓包時是無法抓取服務端的原始響應的，所以就要通過Wireshake獲取服務端原始響應數據，才能更好定位問題；
3.Tcpdump：和Wireshake類似，也是服務端的抓包工具，但是由於Wireshake只有Window客戶端，不能直接在Linux下應用，而實際項目絕大部分都是部署在Linux伺服器的，所以要通過Wireshake和Tcpdump結合的方式，通過Tcpdump抓取數據包並生成文件，再導入到Wireshake中進行圖形化查看和分析。
3.個人總結
本次項目總結除了對個人技術能力進行了提升，對於自身暴露出來的問題，也做了總結，在項目中遇到棘手的問題一定要第一時間進行反饋，如果解決不了要及時協調資源，尋求他人協助時要將業務場景和問題描述清楚，像這次問題定位時實際在之前的項目中處理過類似的環境，但當時用域名的方式並未發生問題，所以在反饋沒有及時反饋，導致前期調整時走了不少彎路，反覆對產品進行調整，後續在工作中一定要避免類似的問題。
對於個人而言，本次工作對於個人能力短板的彌補是非常有用的，因為集成底座項目後續都會採用雲平台的部署方案，基於雲平台環境下網絡、Nginx、產品等相關的配置和處理會顯得非常重要，所以這方面能力的加強非常有利於後續項目的開展。作為一名技術人員，項目實施過程中對於產品、方案、環境等相關知識的熟練程度會直接影響項目交付的效果，影響客戶的直觀感受，有問題不可怕，能夠快速定位、解決問題才能獲得客戶認可和肯定。
本文由@數通暢聯原創，歡迎轉發，僅供學習交流使用，引用請註明出處！謝謝~