Windows中附加IP引起的网络悬案

一.问题背景描述

近期因系统架构升级及业务调整需求，需要在Windows上搭建一套集群环境。集群基本信息如下:

节点     主用地址          Service IP

NodeA   192.168.100.15   192.168.100.17

NodeB   192.168.100.16   192.168.100.17

从整个标题上就可以看到，问题就出在上面的ServiceIP上啦。192.168.100.17是随着服务在两个节点中间来回切换的，那我们首先想到的也是服务通过防火墙、路由器请求外部地址时也通过Service IP出去咯。为了不影响生产环境，接入前先用了个PC配好Service IP的地址进行网络调试，过程如下:

1).笔记本使用Service IP时喜大普奔，很快就OK了，对端地址都可以访问;

2).时间窗口时将集群两个节点切入到生产网络，开心的准备看成功的结果;

3).结果就很悲催啦，整个突然就不通了，对端地址没有问题且测试OK后未进行网络调整。

二.问题排查及处理

确认网络设备上配置没有问题，同时对端地址也正常的情况下。我们就开始去找问题和解决办法咯:

1).不行就先加静态路由:route add 172.28.0.128 mask 255.255.255.255 192.168.100.17

C:\Windows\system32>ping 172.28.0.128

正在 Ping 172.28.0.128 具有 32 字节的数据:

来自 192.168.100.15 的回复: 无法访问目标主机。

2).Ping不到啊，有没有觉得好奇怪。分明就写了静态路由啊，为啥还是从物理网卡上的地址出去的呢？

3).好了，也不卖关子了。直接翻看路由表啊，有一条很神奇的有没有

192.168.100.17 255.255.255.255 在链路上 192.168.100.15

问题大白了，我们指定了静态路由没有错。操作系统会自动在你附加Service IP地址时加一条路由，到达这个Service IP的本机地址还是Public IP。所以外部路由器匹配NAT的时候收到的报文起始位置还是物理网卡的地址，而不是Service IP。处理步骤就如下列出:

1).修改路由器ACL:access-list 1 permit 192.168.100.15;

2).重新连接OK，并检查NAT匹配数量:发现Service IP的NAT匹配也就是在笔记本测试时匹配到过。

show ip nat translations