無論是産品類還是方案類，在實際項目中大部分都是部署在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、産品等相關的配置和處理會顯得非常重要，所以這方面能力的加強非常有利于後續項目的開展。作為一名技術人員，項目實施過程中對于産品、方案、環境等相關知識的熟練程度會直接影響項目交付的效果，影響客戶的直觀感受，有問題不可怕，能夠快速定位、解決問題才能獲得客戶認可和肯定。
本文由@數通暢聯原創，歡迎轉發，僅供學習交流使用，引用請注明出處！謝謝~
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
