双网隔离

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了双网隔离相关的知识，希望对你有一定的参考价值。

参考技术A

双网隔离是一种安全高效的隔离网络桌面云切换方案，TC只需搭配一个网络切换器，通过切换器便能够在物理隔离的网络之间快速切换，达到快速访问另一个网络的桌面云资源，并且物理隔离，提供了高安全性。

监控系统网线拔插事件，当网线被拔插时触发切换流程。切换流程为：找到与当前WI配对的另一个WI地址，并检查到该WI地址是否连通，如果连通则加载该WI地址。

NotifyAddrChange函数主要的功能是用来通知应用程序IPv4地址的变化。注意这个函数仅仅支持IPv4地址的变化，如果需要得到IPv6地址的变化，请使用NotifyIpInterfaceChange。 实战经验：通过NotifyAddrChange侦测网络变化
NotifyAddrChange只是简单的告诉我们系统的IP地址发生了变化，但是具体是怎样变化，我们无法从此函数调用中得到。这个时候，我们可以使用GetAdaptersAddresses这一函数来得到当前最新的IP地址来判断。
根据 GetAdaptersAddresses 接口获取一个网络的详细数据，其中可以获取到IP_ADAPTER_ADDRESSES_LH结构，当中的IF_OPER_STATUS可以知晓网卡状态，为1时表示接口已启动，为2时表示接口已关闭。

网络设备在系统中注册、注销和关闭、打开等事件都可以通知给相应的内核组件或用户空间应用程序，其中内核组件通过netdev_chain通知链获取消息，而 用户空间应用程序则通过注册Netlink RTMGRP_LINK多播群组获取事件消息 。
使用netlink协议，循环从内核中读取创建网络设备的信息，判断状态，后获取网线拔插消息。
通过Netlink检测网线插拔

检测到网络状态改变后，发送信号给主消息流程，执行切换流程：找到与当前WI配对的另一个WI地址，并检查到该WI地址是否连通，如果连通则加载该WI地址。

ICMP：它是TCP/IP协议簇的一个子协议，用于在IP主机路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。
Windows下使用 IcmpCreateFile IcmpSendEcho 两个接口
Linux下，从内核中循环发送和读取ICMP数据包，发送时带一个特定盐值数据，接收时验证。

对每一个需要探测的WI地址，新建一个QNetworkAccessManager实例，并加入一些特定盐值，在 QObject::connect(nam, SIGNAL(finished(QNetworkReply*)), this, SLOT(onAccessibilityFinished(QNetworkReply*))); 回调中检测盐值，实现WI是否可达的探测。

双网隔离环境下CAS单点登录的解决方案

阅读目录

前言

  在单位内架设的Web系统，如果使用CAS作为单点登录方案，往往会遇到从单位的不同网络（例如双网隔离下的外网和内网）访问时，系统无法正常登录使用的问题。基于本人实践，本文介绍一些解决方案。
  本文为原创，首发简书并移植到CSDN，未经许可不得转载。

技术背景

  对CAS很熟悉的朋友可以跳过本章。
  用Java开发一个支持单点登录SSO的Web应用，一般都需要部署两个服务：CAS服务和Web应用服务。CAS的相关资料网上很多，例如:https://www.jianshu.com/p/d443cfc10646。这里只简单叙述一下其工作方式，为解决方案做铺垫。

  1. 开发和部署CAS服务和Web应用服务。假设：
CAS服务地址：http://192.168.1.2:8080/sso
Web应用地址：http://192.168.1.3:8080/web
  1. 在Web应用服务的配置文件中配置CAS服务器的地址。
  2. 用户通过浏览器打开Web应用地址http://192.168.1.3:8080时，Web应用发现用户未登录过（没有session和ticket），于是从配置文件中读取到CAS服务地址，然后把用户当前请求地址附加在这个地址后面，告诉用户的浏览器去跳转到这个地址，形如 http://192.168.1.2:8080/sso/login?service=http://192.168.1.3/web。
  3. 浏览器被重定向到上述CAS服务地址后，出现CAS的登录页面，用户输入账号登录成功后，CAS服务端从浏览器请求地址中提取出用户原来要访问的http://192.168.1.3/web这个地址，附加上ticket后让浏览器重定向到该地址。
  4. 浏览器被重定向到Web应用地址：http://192.168.1.3/web，Web应用服务端收到用户请求，并从请求中获取到sessionid、ticket等信息，然后在后台去访问http://192.168.1.2:8080/sso，验证ticket通过后即响应浏览器请求，通知浏览器重定向到Web应用首页。整个登录过程结束。

问题描述

  当系统只在一个独立的网络中运行时，CAS登录过程没有任何问题。但如果企事业单位采用了网络隔离模式，典型地，把网络分成内网和外网两部分，服务器部署在内网，通过端口映射的方式把服务端口向外网开放，外网用户只能通过外网IP访问单位网络。此时外网用户将无法完成单点登录过程。原因如下：
  假设单位的外网地址是10.11.2.3，并且已经成功地做了如下端口映射：

CAS服务外网映射：10.11.2.3:81 -> 192.168.1.2:8080
Web服务外网映射：10.11.2.3:80 -> 192.168.1.3:8080

  当一个外网用户输入 http://10.11.2.3:80/web时，端口映射能够成功将请求转给内网的http://192.168.1.3:8080/web，而Web应用的配置文件中登记的CAS服务地址是内网地址http://192.168.1.2:8080/sso，因此Web应用会通知浏览器重定向该地址。然而浏览器是处在外网网络中，当然无法连上该内网地址，于是浏览器报错，登录过程中断。作为用户，会看到浏览器地址栏显示一个内网URL。

问题分析

  出现登录问题的本质原因是：
  CAS登录过程依赖对CAS服务地址的重定向，而这个地址是在部署系统时固定配置好的，唯一的。如果内外网不能同时访问该地址，则必定无法登录成功。 上例中，外网用户无法访问http://192.168.1.2:8080/sso这个地址。
  要解决该问题，思路就应该是：用什么方法能够使得***在重定向跳转过程中，始终都使用当前用户可以访问***的地址。

解决方案

  长话短说，这里直接给出几个可能的解决方案。

解决方案1：通过统一域名和DNS解决

  这是最简单优雅的解决方案。
  简单说来，上面的例子中因为使用了IP地址作为服务地址，从而造成内外网无法同时访问的结果，那么把IP地址改成域名，通过内外网不同的DNS域名服务器设置，让无论内网还是外网都能通过域名访问到真正的服务地址，此问题就迎刃而解。具体做法如下：

  1. 给SSO服务和Web服务申请域名：
SSO服务域名：sso.mycompany.net
Web应用域名：web.mycompany.net
  1. 在Web应用服务的配置文件中，配置CAS服务的地址为：http://sso.mycompany.net:8080/sso。
  2. DNS配置：
  • 在内网的DNS服务器上，把这两个域名分别映射到192.168.1.2和192.168.1.3；
  • 在外网申请两个IP地址IP1和IP2（满足特定前提下可以只用一个，参见后文），并分别在外网的DNS服务器分别绑定两个域名到这两个IP地址；
  1. 端口映射：分别把IP1和IP2的8080端口映射到内网的192.168.1.2和192.168.1.3的8080端口；
  2. 告诉内外网所有用户，应用的访问地址是http://web.mycompany.net:8080/web

  上述工作完成后，无论内网用户还是外网用户，当访问http://web.mycompany.net:8080/web时，浏览器都会被重定向到http://sso.mycompany.net:8080/sso来进行单点登录，而这个地址都会根据所在网络不同，解析并导向到最终的内网服务器上，从而实现成功登录。
  该方案的一个小小缺陷是因为地址必须相同，所以内外网必须使用相同的服务端口号，即如果内网服务使用了8080，外网也必须使用8080。上述的例子中，因为cas和web都使用了8080端口，因此外网不得不用两个外网IP地址来分别映射。如果cas和web的端口不同，则可以只使用一个外网IP地址的两个端口来分别映射，此时外网DNS把两个域名映射到同一个IP地址上即可。
  遗憾的是，现实中很多单位的IT部门要么难以搞定域名申请和配置，要么因为懒而直接甩锅给业务系统开发商，要求从应用层去解决，总之因为各种客观限制，这个最优雅最简洁的方案却是最难推动的。

解决方案2：通过应用程序端解决

  首先说明，这是***绝对不建议***采用的方案。这里仅仅作为一种可能性简要介绍一下思路。
  回顾上述的失败流程，因为Web应用对外网用户给出了错误的内网CAS服务地址，从而造成外网用户无法登录，那么理论上如果Web应用能够识别出外网用户，并让其重定向到正确的外网CAS地址，则有可能解决此问题。具体来说，需要Web应用通过用户的HTTP请求中的信息判断用户来自哪里（例如是否来自外网与内网之间的网关），区分内网和外网给出不同的重定向地址，并解决后续从CAS跳转回Web应用地址、网页中的超链接地址动态切换等一系列问题。
  此方法过于麻烦，配置复杂，需要对系统源码动手，如果CAS后面对接了多个系统（之所以要上SSO，肯定是应用系统数量比较多对不对？），这工作量……更别说如果这些系统的源码不在你手上或根本就是别的公司开发的，涉及到复杂的协调问题，那就更难进行了。故该方案在此不再展开，后面有参考链接，可直接看。本人之所以提这个方案，是因为公司里曾经有程序猿试图采用这种方式解决，结果遇到刚才说的工作量、第三方协调等问题，搞不下去了……
  下面几篇文章都是该方案的思路，供参考：

解决方案3(推荐！)：通过Apache/Nginx反向代理

  各位看官，你们是否和我一样，都很累了。。。打起精神，铺垫了这么多，现在终于到本人想重点讲解的方案了，敲黑板！！！
  本方案的核心思想是，在内网架设一台Apache/Nginx服务器，通过端口映射向外网用户提供系统访问入口，利用Apache的反向代理能力，把内网服务器生成的重定向内网地址，转换成外网地址，再传给外网用户浏览器。整个方案不需要对CAS和应用做任何配置或源码上的修改！ 简单的示意图如下：
  上图中，内网用户的访问方式完全不变，CAS服务和Web应用也不做任何调整，对它们来说，完全不知道自己会被外网用户访问。而外网用户则需要通过被端口映射到外网的Apache服务器间接访问CAS和Web应用。
  注：Nginx是比Apache功能更专一的反向代理软件，不过因为本人工作史的缘故，本方案是基于Apache的（我才不会说我其实没怎么玩过Nginx），好在都差不多，用Nginx的童鞋就麻烦参照本文思想自行实现吧。
  Apache的安装部署过程略去，直接进入配置环节。

配置1：定义VirtualHost，开启反向代理

  在Apache的配置文件中，定义VirtualHost，监听8080端口，并指定ServerName 10.11.2.3，意思就是该VirtualHost中的配置仅当接收到的请求URL中的主机名是10.11.2.3时才起作用。其他几个配置就不一一说明了。

# 外网地址
<VirtualHost *:8080>
    ErrorLog "logs/error.8080.out.log"    
    ServerName 10.11.2.3

    # 关闭正向代理
    ProxyRequests Off
    # 反向代理时不保留原始Request中的HOST（即代理服务器自身Host）
    ProxyPreserveHost Off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
</VirtualHost>

配置2：反向代理

  在VirtualHost中，通过ProxyPass和ProxyPassReverse两个指令，实现URL反向代理：

# SSO反向代理
ProxyPass /sso http://192.168.1.2:8080/sso
ProxyPassReverse /sso http://192.168.1.2:8080/sso

# Web应用反向代理
ProxyPass /web http://192.168.1.3:8080/web
ProxyPassReverse /web http://192.168.1.3:8080/web

  ProxyPass指示Apache接收到某个路径请求后，需要把请求转发给哪一个地址。例如:

ProxyPass /web http://192.168.1.3:8080/web

  这句话的意思是，当Apache收到的请求路径是/web开头时，需要把请求原封不动地转发给http://192.168.1.3:8080/web（/sso后面URL的其他部分也会原样附加上去），然后把http://192.168.1.3:8080/web返回的Response，再原封不动地返回给正在访问Apache的浏览器。这个过程对浏览器是透明的，实现了用户输入外网地址就能看见内网系统页面的效果。
  不过，ProxyPass无法处理重定向。当http://192.168.1.3:8080/web的响应报文的HTTP头中带有Location重定向标识时，浏览器会不折不扣按此标识跳转。在本文开始的例子中就说过，Web应用返回给访问者的重定向地址是内网地址。在通过Apache返回时，必须把这个内网地址改成外网地址，这就需要用到ProxyPassReverse指令。例如：

ProxyPassReverse /sso http://192.168.1.2:8080/sso

  这句话的意思是，如果Apache接收到的服务器响应中重定向标识Location是http://192.168.1.2:8080/sso，则将其替换为当前用户访问地址后加上/sso。这样，web应用本来是要求浏览器重定向到http://192.168.1.2:8080/sso/login?xxxxx，但这个地址在经过Apache返回时被Apache篡改成了http://10.11.2.3:8080/sso/login?xxxxx，浏览器并不知道这一切幕后工作，只是单纯按照接收到的信息进行重定向，去请求http://10.11.2.3:8080/sso/login?xxxxx。该请求再次经过Apache并被ProxyPass指令转换成真正的内网CAS服务器地址，从而能够正确到达CAS服务器。后面过程就不详述了。
  总之，通过这两个指令就基本实现了在不对应用系统做任何配置修改的情况下的外网访问。
  值得一提的是，上面的例子中CAS服务和Web应用的URL都是带有子路径/sso和/web的。这里有两个最佳实践：

  • 在做反向代理时，最好让系统运行在某个子路径下，而不要运行在根路径下；
  • Apache/Nginx上的反向代理配置，最好配置与后方系统相同的子路径做为映射路径；

  按上述最佳实践来做，能够省掉很多麻烦事。
  如果系统运行在URL根目录下，即http://192.168.1.3:8080，而不是http://192.168.1.3:8080/web，在做反向代理配置时就需要把路径映射到根路径，如果有多个后方系统都使用根目录，反向代理将无法区分。有人一定会说使用ServerName、多IP地址、多端口等方式可以实现根据不同请求来源而区分处理，但现实是我遇到的大多数单位提供的对外访问接口，既没有域名，也没有多个IP，甚至也不会给你开多个端口，这种情况下，只能靠子路径来让反向代理知道应该到哪里去。那位说了，可是已经部署好的系统就是在根目录的，我怎么办？好吧，你施展人格魅力的时候到了，想办法去说服他们改变吧！如果魅力不够，也许你可以在内网再架设一个反向代理做二次映射来专门解决这个特定应用的路径问题，我也没试过行不行，祝你成功，并且成功后告诉我一声:-）
  如果映射的子路径和系统真实的子路径不同行不行呢？比如说CAS服务地址是http://192.168.1.2:8080/sso，我在Apache上配置用/cas路径来映射，即对外的地址为http://10.11.2.3/cas，有什么问题？答案是，不一定，但有可能会遇到问题。这个问题通常出在一些系统在开发或部署时，有可能把这个子路径作为系统变量的一部分，在页面超链接等地方直接使用/sso，因为Apache无法识别和处理这个地址，所以页面也就无法正常显示。总而言之，不要自找麻烦，简单点，生活尽量简单点。

配置3：页面内容替换

  完成上述反向代理配置后，其实大多数系统就已经能够正常使用了。不过偶尔还会遇到一些系统在页面上直接超链接其他系统的，比如一个门户系统在页面上超链接其他业务系统的地址是再正常不过的了。超链接只能写一个URL，要么是内网的，要么是外网的，怎么同时满足内网用户和外网用户呢？前面的反向代理配置，不会处理页面中的URL，此时就需要用到另一个大杀器：mod-substitute。
  Apache的mod-substitute模块可以通过正则表达式，实时替换网页中的内容。具体语法参考请移步原厂：mod-substitute。下面是配置实例：

##去掉GIZP标识，否则无法替换页面内容
LoadModule headers_module modules/mod_headers.so
RequestHeader unset Accept-Encoding    
## 加载替换模块，过滤指定类型页面
LoadModule substitute_module modules/mod_substitute.so
AddOutputFilterByType SUBSTITUTE text/html
AddOutputFilterByType SUBSTITUTE text/plain
AddOutputFilterByType SUBSTITUTE application/json
AddOutputFilterByType SUBSTITUTE application/x-javascript
AddOutputFilterByType SUBSTITUTE application/javascript
AddOutputFilterByType SUBSTITUTE text/javascript
## 把服务器响应中的内网IP地址改成外网地址
Substitute "s|192.168.1.3:8080/web|10.11.2.3/web|n"
Substitute "s|192.168.1.2:8080/sso|10.11.2.3/sso|n"

  上面的配置中，首先重置Accept-Encoding，这实际上就会去掉浏览器发出的请求头中支持gzip的申明，于是服务器就不会返回经过压缩的页面内容，这样才能够进行文本替换。AddOutputFilterByType指明要进行替换的Content Type种类，显然这里应该根据系统的实际情况，列出所有有可能出现系统URL的地方，越少越好，像图片之类的当然就不需要了，因为这玩意肯定影响性能。Substitute进行实际的内容替换，注意前面的地址是被替换内容，后面的是替换内容，别写反了啊！
  通过上面的配置后，从外网尝试打开原来有错误链接的页面，看看链接地址是不是被改变了？当然你可以拿页面中的任何内容测试一下，比如把版权信息改成“圣诞节快乐”，把你情敌的姓名改成公司领导姓名，看看用户反应如何？我就是说说而已，被投诉了可别找我啊！现在知道为什么我说这个东西是大杀器了吧，随意篡改网页内容太可怕了有木有！网络世界真的不能没有SSL、HTTPS！如果系统本身已经使用HTTPS方式部署，这方法可能会失效，参见后面的专项讨论。
  最后强调一下，这个配置会降低性能，对HTTPS可能会无效，仅当网页内容中出现了系统URL绝对路径且需要动态替换时才考虑使用！

一个完整的配置文件

  最后放出一个完整的配置文件。给这个文件随便起个名字，只要扩展名是.conf，单独放在Apache服务器的conf.d或类似目录下（好像不同版本不一样？），重启Apache就可以生效了。

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule substitute_module modules/mod_substitute.so
LoadModule headers_module modules/mod_headers.so

NameVirtualHost *:8080

# 外网地址
<VirtualHost *:8080>
    ErrorLog "logs/error.8080.out.log"    
    ServerName 10.11.2.3

    # 关闭正向代理
    ProxyRequests Off
    # 反向代理时不保留原始Request中的HOST（即代理服务器自身Host）
    ProxyPreserveHost Off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
	
	##去掉GIZP标识，否则无法替换页面内容
	RequestHeader unset Accept-Encoding    
	## 过滤指定类型页面
	AddOutputFilterByType SUBSTITUTE text/html
	AddOutputFilterByType SUBSTITUTE text/plain
	AddOutputFilterByType SUBSTITUTE application/json
	AddOutputFilterByType SUBSTITUTE application/x-javascript
	AddOutputFilterByType SUBSTITUTE application/javascript
	AddOutputFilterByType SUBSTITUTE text/javascript
	## 把服务器响应中的内网IP地址改成外网地址
	Substitute "s|192.168.1.3:8080/web|10.11.2.3/web|n"
	Substitute "s|192.168.1.2:8080/sso|10.11.2.3/sso|n"

	# SSO反向代理
	ProxyPass /sso http://192.168.1.2:8080/sso
	ProxyPassReverse /sso http://192.168.1.2:8080/sso

	# Web应用反向代理
	ProxyPass /web http://192.168.1.3:8080/web
	ProxyPassReverse /web http://192.168.1.3:8080/web
	
</VirtualHost>

调试技巧

  在调试Apache/Nginx的反向代理配置时，需要熟练掌握一些方法：

  • 启用浏览器的调试功能（按下F12键），学会查看Request、Response中的信息，主要就是Header的内容。尤其是在重定向时，注意查看Response中的Location的内容是什么。
  • 在Chrome的调试窗口中，要勾选Preserve Log选项（如下图），否则在页面跳转等场合会漏掉跳转后的请求记录。

关于HTTPS

  前面的讨论，都是建立在内网系统本身是HTTP服务，而不是HTTPS服务的前提上进行的。如果客户要求通过HTTPS访问系统，需要如何做呢？这里有两种方式实现：

  1. 应用服务器本身就以HTTPS方式部署
  2. 应用服务器以HTTP方式部署，通过Apache/Nginx转换成HTTPS给用户访问；

  第一种方式是网上讲解配置SSL的文章采用最多的方式。根据HTTPS的原理特点推测，Apache/Nginx应该无法同时满足即解密处理HTTP数据，又让客户端一无所知（更换证书是属于客户端可感知的），因为这种方式就是典型的中间人攻击。从网上资料来看，Apache是可以进行SSL代理的，搜了一篇 帖子供参考。我想原理上应该就是Apache先用服务器公钥解密，然后再用Apache上配置的证书重新做加密，与浏览器交互。浏览器看到的证书是Apache提供的。
  第二种方式是我重点推荐方式。当需要提供HTTPS服务时，只在反向代理Apache/Nginx层进行设置，而源应用总是使用HTTP。这样做的好处是当业务系统很多且都可以使用子路径部署方式时，只需要配置一次证书（因为主URL相同，只有子路径不同），能够减轻配置工作量。当应用服务器需要集群、多个系统多个域名多个入口等情况下，即使需要配置多个证书，能够只在反向代理服务器上一次性干完所有工作，不用慢吞吞地重启Tomcat等应用服务器，毕竟Apache/Nginx都可以秒起甚至热加载，这是何等幸福！这算是一个最佳实践吧，以后有时间我可以再写一篇详细文章介绍。
  回到本文主题，前面介绍的方案在这两种场景下是否可以沿用呢？第一种场景我没有试过，估计可行，如果有人试过请留言说一下结果。第二种场景则是亲测通过的，亲们可以放心使用。

结束语

  这篇文章所记述的方案，来自于一年多前的项目实际经验。最近又遇到有同事在咨询相同的问题，而网上没有看到特别清晰实用的方案，于是利用闲暇写就此文。因为隔的时间比较久，当时一些细节已经记不清了，如果有什么错漏，请各位看官给指出啊！
  最后，这篇文章花费了我一天时间，如果它帮到了你，请点个赞哦！

以上是关于双网隔离的主要内容，如果未能解决你的问题，请参考以下文章

适合银行高端制造业使用的跨网文件安全交换解决方案

谈谈高可用之隔离

mysql 的事务隔离级别 及各个隔离级别应用场景,详细

kafka资源进行物理隔离

微隔离：下一代网络隔离控制技术

Spring框架默认事物隔离级别