广积粮、高筑墙(2)——偷天换日,布真假网关;剑走偏锋,玩无缝割接

前言:本文仅限以太网环境,对PPP、PPPOE等不适用。

这世界上有三种人:

第一种,遇到问题时会说,别人用过的办法都不行,那我们自己想办法吧。

这个时候,第二种人说,从来没听说过有这种做法,你这个肯定行不通的。

第三种人则在旁边说:“静态路由怎么可能支持负载分担?那vrrp还有什么意义?这么做不会路由成环么?”、“二层转发一定会走网关的,不信你回去试。”、“在交换机上做ACL?不行不行不行,从来没听说过这么用的。”

第一种人,我们可以用一个形容词来形容,那就是——牛B

第二种人,我们同样可以用一个词来形容,那就是——不牛B

第三种人,仍然可以用一个词来形容,那就是——特tm不牛B

所幸,哥在刚入行时,遇到的就是第一种人。虽然哥的惰性决定哒哥这辈子不太可能成为第一种人,但是哥也一直在努力,争取不要成为后两种人

而不幸的是,今年遇到很多特tm不牛B而且还更tm自以为是的人。而刚好,前不久又被一个遇到的问题逼得自创哒一套独门绝技,今天就让哥舞剑助兴,为第三种人点上一曲《外面的世界很精彩》,欢迎它们跳出井底来看看吧。

如果要完全还原哥当时的思路,抽丝剥茧,对那些特tm不牛B的人来说,无论是技能水平还是情感层面都会难以接受,所以,哥决定使用倒叙的方法,直接说茧。

首先,我们来颠覆一个传统:

所有电脑需要访问互联网,都需要配置一个网关,或者说缺省路由,通常,这个网关都需要与这台电脑在同一网段。辣么,有没有可能用一台不在同一网段的IP作为自己的网关呢?显然,是可以的。不信?看哥演示一下。因为这个完全是原理层的东西,不限厂家不限设备不限版本,结果都是一样的,所以,我们用两台路由器来做这个演示:

见上图,用R1模拟电脑或者其它任意网络设备,接口IP为1.1.1.1/30,与之直连的R2的IP为2.2.2.2/30,显然,它们不在同一网段。现在,看看能否把R2作为R1的网关。首先,我们在R2上配置一个loopbadk地址3.3.3.3,用来模拟互联网上的一个随机用户。对R1来说,如果能够访问3.3.3.3,就一定能访问互联网上的其它IP(这里假设外面的路由一切正常)。

来回忆一下三层转发的原理:

设备发现目的IP与自己不在同一网段时,会查找路由表,并确定下一跳的IP地址。

确定好下一跳的IP地址后,通过查询已有的arp列表或发起arp请求,去获取这个IP对应的MAC地址。

将这个MAC地址封装到报文中,指定其为目的MAC,并将报文从网卡丢出去。

通常,达到目的的路径会有多条,只要能达到目的地,走哪条路径并不重要。所以,我们可以把上面的这个流程稍加修饰:

在R1上配置一条缺省路由,下一跳的IP为1.1.1.2,而实际上,这个IP地址是不存在的。

在R1上配置一条静态arp,将1.1.1.2的IP地址映射到R2的接口MAC上,即2.2.2.2/30的MAC地址。

在R2上执行同样的操作,将1.1.1.1/30的路由下一跳指向2.2.2.1,同上面的1.1.1.2一样,这个IP地址也不存在。

在R2上也配置一条静态arp,将2.2.2.1的IP地址映射到R1的接口MAC上,即1.1.1.1/30的MAC地址。

这个时候,在R1上ping 3.3.3.3,发现已经通哒,而且tracert发现,第一跳就是与自己不在同一网段的2.2.2.2。

R1配置:

ip route 3.3.3.3 255.255.255.2551.1.1.2

arp 1.1.1.2cc02.0c1c.f000arpa //这个MAC实际上是2.2.2.2的

R2配置:

ip route 1.1.1.1 255.255.255.2552.2.2.1

arp 2.2.2.1cc01.0c1c.f000arpa //这个MAC实际上是1.1.1.1的

辣么,为什么哥这么蛋疼整天琢磨这些东西呢?其实并没有。虽然很早就受到牛人的启发,这些年来一直致力于解决那些看起来无法实现的东西而且小有成就,但是,之前却一直没想过这么简单的地方其实也有变通的余地。而这次,完全是因为被一个问题难到哒才想到这个办法的。

而这个问题就是,要在下面这个环境中部署一个过渡网关,将上下行的流量逐步切走(每天切一点,以便于观察网络情况),而且切换过程中要求完全不影响业务。当所有流量切换到过渡网关后,对现有的网关执行设备替换或者软件升级操作,而哥后来却发现这个网段的IP已经耗尽,根本没有多余的IP提供给过渡网关使用。

通过上面的小实验可以得知,当内网IP耗尽,没有空闲IP提供给过渡网关时,我们可以在过渡网关路由器上任意配置一个其它网段的IP地址来实现流量切换。比如内网用的是172.16.18.16/28,辣么可以在过渡网关上配置一个10.0.0.1/24来实现流量切换,看起来似乎已经大功告成。但是,前面说过,哥很懒,所以,哥又想哒一下,看有没有更简单而且更保险的办法来操作。显然,这个答案仍然是肯定的。

172.16.18.16/28的可用IP范围是172.16.18.17-172.16.18.30,这里显然浪费哒两个IP,一个是172.16.18.16,另一个则是172.16.18.31。所以,我们可以用这两个IP来做文章,这样,对过渡网关来说,内网这些服务器与自己就在同一网段,因此也就不需要对每台服务器都配置一条路由哒,这样,对上面实验中R2的配置来说,工作量就少哒一半。

但是,172.16.18.16/28和172.16.18.31/28明明是无限的,怎么可以用呢?好说好说,只需要稍做修改,把/28变成/27即可,这时,172.16.18.16/27就变成为有效IP哒。

但是显然,这里有个坑:

172.16.18.0/27=172.16.18.0/28+172.16.18.16/28。

也就是172.16.18.0/28这个网段的IP(下文称其为“无辜群众”),明明是在外面,此时却变成哒R2的直连路由。但是,这个坑也非常好填,那就是指一条172.16.18.0/28的路由出去即可。

好,现在这个框架就搭建完成哒。需要配置的具体内容如下:

现有网关设备:不做任何修改。

过渡网关:

配置一条缺省路由。

配置一条用于保护无辜群众的路由172.16.18.0/28,下一跳与缺省路由相同。

配置内网服务器的静态ARP列表(这一步建议配置,因为谁也不知道当下面的服务器发现发起arp请求的IP是自己网段的网络IP时,是否会将其视为无效而不予响应),还是那句话,一切从最坏角度出发,不要挖坑

服务器:配置静态arp,在不修改网关IP的前提下,将MAC地址配置为过渡网关的MAC地址,即将172.16.18.17/28的IP映射到172.16.18.16/27的MAC地址上。

[root@CentOS ~]#arp –s 172.16.18.17 68:2c:7b:6c:25:47

//这个MAC实际上是172.16.18.16/27即过渡网关的

[root@CentOS ~]# arp -an

? (172.16.18.17) at 68:2c:7b:6c:25:47[ether]PERMon bond0//静态arp

最后一步,在外网的路由器上修改路由,将入方向的流量指向过渡网关即可。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181021G1J8O000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券