另类的ip地址伪装折腾记

收到这样一个需求：在现有结构不变的情况下，让被访问方看起来是很多物理地址在同时请求。为了便于大家理解，我画个图来描述，就明白了。

新的业务规定是这样，见下图

这样一来，就没有中间那个“业务处理服务器”什么事情了。可是，那么多的终端，却是自己辛苦发展起来的，投入了大量的精力和资金，不可能不做了啊。因此，要想个办法，让最终处理服务器看起来，是很多终端在访问它。

基本的思路是申请一大批ip地址，然后跟服务器做绑定，即中间那个业务服务器设置数百个ip地址，体系结构不做任何变化。

经过讨论，大家一致认为这样可行（打查遍球，嘿嘿！），接下来相关人等联系机房，看申请ip地址什么一个费用。第二天，得到反馈，每个ip地址每个月多少银子，但另外一家的报价比现在托管的这家还低。问低多少？答：“低三分之一”。还吩咐我，准备把服务器整体搬走。我一听，心里一惊，这搬迁都要命啊！一整柜的服务器，业务还很复杂，不光自己的系统在处理业务，还有与第三方机构的系统进行交互，记得当时跟那些三方机构联调的时候，可费劲了（经常找不到人，配合不得力）。这要是搬迁，好久能恢复业务，没法预估时间。

从这个图可以看出，整个结构还是比较复杂的，在没有充足资源的条件下，直接停机搬迁，完全是找死啊（正常的搬迁，需要在目的机房全新部署差不多规模的设施，然后迁移应用，这样多花好多银子的）！权衡再三，我个人觉得不要搬迁，于是跟现有机房进行交涉，要求便宜一些，不然客户要跑了。经过多轮沟通，价格降了不少，可还是没有挖墙脚那方报价低。最后，相关决策人，还是决定用另外一家的ip，并要求几方去现场讨论方案。

在去讨论的路上，我心里还是不想把它们搬走，太费劲了。要是恢复不了业务，压力全在我这里；特别是oracle 11g rac，出故障了不是一时半会能恢复得了的。突然，有了这么一个方案：现有机房不动，通过***连接到挖角机房的***，然后再在那里做地址绑定。到现场后，另一方人还没来，我就跟决策人讲了厉害关系以及解决方案。记得最关键的一句话是“咱们能忍受多长的停机损失”!技术副总说了一句：“停一天的损失，够我们托管好几年了”。没多久，那帮人来了，说了我的方案，经确认，可行。

目前，机房已经有一个dlink的***，型号是DI8200；厦门某个机房托管的设备正好要下架撤回来，刚好有个花三的***。等设备到了以后，就把它放在新租赁的机柜。在现有的dlink上，新增一条ipsec隧道，很快就做好了。然后登录另外一个机房的华三，配置ipsec，配完后，死活不通。仔细对比，发现有几个项目，不管怎么修改，始终对不上，如下图所示：

通过咨询各路好手，判定两种设备不兼容。只得重新选用相同的设备来做这个同道，于是又买了一个同型号的dlink DI8200，设置好ipsec，测试两个网络的内网服务器，终于能互访了。接下来，就是处理ip地址绑定的事情了。

设计好的***隧道结构如下图所示：

接下来，我们需要测试内网服务器访问某个指定目标服务器，看访问通路是否跟我们期望的一致。遗憾的是，访问是从本地那个***的默认路由出去了，没有通过建立起来的那个***隧道，只有访问对端的内网，才会走***隧道。折腾了两天，怎么弄也不行，有人说低端的***不支持，并且给出了建议，买功能强一点的***设备。征得决策人同意后，放弃现有的一对***。

有过来几天，设备采购回来，上架联网后，继续干活。这次使用的是一对juniper SSG20，我自己弄了半天，弄不好，就找外援帮忙。等同道配置好以后，对方再在出口网关（一台二手F5）做地址池，把数百个ip地址都绑定上去了。

联系好目标方，让其对我方开放一个web服务。我这边在内网服务器上加上到目的地的静态路由，先traceroute 过去，看经过的路径，是不是设定好的那条***隧道。确认无误以后，我在内网服务器，写了一个简单的脚本，循环访问目的端url 1000次，查看目的端web日志，确实是无数个不同的ip地址轮换请求，到达了目的。

最后，再把***隧道配置的信息贴在此处，供大家参考（关键点就是两处，一个是设置IKE，另一个就是隧道的网关）。