我的第一个DMZ方案实践

方案提出的初衷:外网需要定时和不定时推送数据到内网服务器(只要求数据到达内网,没有要求直接连接到内网)

为什么不是直连到内网:每个人第一想到的是不安全,是的,没错不安全。内网的应用和外网的应用最明显的区别就是承载的访问量,虽然都应该配置防恶意攻击策略,但是内网的应用一般不会像外网的应用考虑那么多安全的策略。所以这里的安全,包含防窃取资料的安全性、恶意攻击以及给hacker留了后门等因素。(我想的是这些)

所以,专门留一台外网可以访问的机器A,外网把数据推送到机器A,然后内网的应用B去机器A PULL 数据。

怎么去PULL数据?

有两种方式:

第一,定时去机器A PULL,缺点有延时,如果每隔20分钟取一次数据,最长延时为20分钟。如果外网推送本来就延时推送,那么数据状态实际产生的时间到达数据的最终消费者的时候,延时更长。

第二,监听机器A,当机器A上一旦有可用数据的时候,就PULL过来。(我采用的是这种方案)

监听机器A怎么监听?

第一,可以自己写个程序,建立请求连接,机器A保留连接请求不立即响应,等到机器A上有可用消息的时候,再响应。(相当于我们在HTTP里面经常说的 long connection)

第二,使用MSMQ的reveive方法,这个方法本身就实现了这样的机制,当MSMQ中有可用消息时Receive才返回消息。这里需要合理建立专门的消息队列。

推送消息怎么到达数据消费者C?

监听机器A是否有可用消息的服务,我们暂且称为“数据转发服务B”,转发服务可以独立部署,也可以部署在消费者C里面。

我最初把转发服务部署在IIS上,并且设置应用程序池不回收,即“固定时间间隔”设置为0,“限制超时”也设置为0,但是过几个小时后,这个转发服务还是会“休息”,需要访问这个站点的一个页面,使服务“醒”过来。服务没有死,只是可能闲置了,被回收了。具体原因望高手支招。

后来把转发服务配置到了windows服务,这样不会有应用程序池被回收的问题。

数据消费者C需要公开一个接受“推送数据”的服务,转发服务将PULL得到的数据 转 给 该服务。

这样的完整流程我实现了,目前运行正常,但不知会有什么潜在问题?望高手支招。

以上叙述中,机器A是处于DMZ中的。

备用方案:

由于推送数据经过了两个中间机器,机器A和转发服务处于的机器,如果哪天不能用了,让数据消费者B临时主动请求外网API去获得数据,这样对消费者B是有压力的,所以不建议这样使用。

小插曲,就因为后期做了一个主动请求外网API的备用方案,上线测试的时候,没有考虑到生成环境的数据库有上万的历史数据,导致系统异常发了上万条异常邮件。因此被记过加现金处罚。

posted @ 2015-04-30 18:55  二师弟tl  阅读(1757)  评论(1编辑  收藏  举报