另类的地址伪装折腾记

另类的ip地址伪装折腾记

收到一个请求:在当前结构不会改变的情况下，让被浏览方看起来像是很多物理地址在请求另一个请求。为了让大家更容易理解，我画了一张图来描述，我明白了。

新的业务流程需求就是这样，如下图所示。

这样，中间就没有“业务流程解决方案服务器”了。但是终端设备那么多，真的是自己辛辛苦苦开发出来的成果。基金投入了大量的精力和资产，退出的可能性不大。所以要想办法让最终的解决方案服务器看起来像是很多终端设备在浏览。

基本思路是申请大量ip详细地址，然后关联服务器，也就是中间哪个业务流程服务器设置几百个ip详细地址，系统架构不做任何改变。

大家讨论后一致认为可行(检查所有球，哈哈哈！)，然后相关的人联系机房，看看申请详细的ip地址需要哪个费用。第二天，我得到了反馈。每个ip详细地址每个月多少银子，但是另外，一家的价格比现在管理的还要低。低价是多少？答:“低三分之一”。还告诉我提前准备把服务器整体搬走。听到这里，我惊呆了。这个拆会死人的！一个盒装服务器的业务流程还是很复杂的。不仅自己的系统软件解决业务流程，还与第三方机构的系统软件进行交互。我还记得当时和这些三方机构协调是费了很大力气的(往往人不多，相互配合性不强)。如果拆除，修复业务流程需要很长时间，无法预计时间。

从这个图可以看出，整个结构还是很复杂的。没有足够的资源，马上关机拆机就是彻底的死(所有正常的拆机都要在目的机房升级部署类似规模的设备，然后转移使用，要花很多钱)！权衡再三，觉得没必要强拆。所以我和现在的机房商量，让它更划算，不然客户就跑了。经过积累沟通交流，价格降了不少，但没挖墙角的那一面价格还是低的。最终，相关管理决策者决定使用另一家公司的ip，并约定几方当场讨论方案。

在探索的路上，我还是不想把它们搬走。太费力了。如果业务流程修不好，工作压力全在我身上；特别是Oracle11grac，常见故障无法在短时间内修复。突然有了这样的打算:目前机房没动，按*****连接到角落的房间，然后在那里做详细的地址关联。到了现场，对方还没来。我也把强连接及其解决方案告诉了管理决策者。记住最重要的一句话是“我们还能承受多久的停机伤害”！技术总经理曾经说过，“停一天造成的伤害，足够大家打理很多年”。很快，那帮人来了，谈了我的计划，被证实可行。

目前机房已经有一台dlink**了，型号规格是DI8200；厦门一个机房代管的机器设备刚停售出去，就有一花三***。机器设备到货后，放在新租的服务器机柜里。在当前的dlink上，增加了一个ipsec隧道，而且很快就完成了。然后，华三，谁降落在另一个机房，配备了ipsec。装备之后就被屏蔽了。仔细对比发现，几个新项目，无论怎么改，从头到尾都不一样，如下图:

根据各行各业的咨询专家，判断两种机器设备的兼容性。再一次，我们只能用同样的机器设备来做这个志同道合的人，于是我们买了同样的dlinkDI8200，设置了ipsec，检测了两个互联网的内网服务器，终于可以互相访问了。接下来就是解决ip详细地址关联的问题。

设计的***隧道施工结构如下图所示:

接下来，我们必须检查内部网服务器浏览特定的整体目标服务器，以查看浏览通道是否与我们的预期一致。遗憾的是，浏览是基于本地***的默认路线，没有创建哪个***隧道建设的依据。只有浏览对面内网，才会走***隧道施工。折腾了两天，怎么做都不好。有人说低端的***不兼容，想出一个建议，买更强大的***机器设备。在征求管理决策者的意愿后，抛弃现在的一对***。

回来没几天，就买好了机器设备，放出了连接网络，又开始工作了。这次用的是一双杜松SSG20。我自己做了很久了。如果我做不好，我会请外国选手帮忙。相当于网关配备后，对方在网关ip(一个二手F5)做了一个详细地址池，关联了上百个ip详细地址。

联系整体目标方，让其向己方开放web服务。我这里在内网服务器上添加到达站的静态路由，先追踪路由，看看路由是否经过，建立了哪个***隧道。确认无误后，我在内网服务器写了一个简单的脚本，在一个循环系统里浏览了1000遍目的地url，查询了目的地web日志。果然是无数个不同的ip详细地址交替要求，我到达了目的地。

最后***隧道建设的信息内容就贴在这里，供大家参考(关键环节很多地方，一个是设置IKE，一个是隧道建设的网关ip)。