集成底座内外网访问配置说明

无论是产品类还是方案类，在实际项目中大部分都是部署在 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、产品等相关的配置和处理会显得非常重要，所以这方面能力的加强非常有利于后续项目的开展。作为一名技术人员，项目实施过程中对于产品、方案、环境等相关知识的熟练程度会直接影响项目交付的效果，影响客户的直观感受，有问题不可怕，能够快速定位、解决问题才能获得客户认可和肯定。