注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Tsecer的回音岛

Tsecer的博客

 
 
 

日志

 
 

两台主机互为网关是否会像打乒乓球一样一直互发  

2017-03-11 21:26:58|  分类: 计算机网络 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
一、臆想的一个问题
一直比较好奇一个问题,或者说是一个恶作剧:假设说A、B两个主机互为网关,A需要发送一个数据,根据自己路由配置数据被发送给B主机;数据到达B主机之后,B主机检查自己的路由,发现网关是A主机,这样就会将这个数据(递减TTL之后)再次回传给A主机。这个过程是否会这样一直继续下去呢(当然,是在TTL还没有降到零的前提下)?
二、测试环境的准备
在单PC的环境下其实是没有办法测试这个环境,为了搭建这个环境,可以考虑在Linux环境下搭建一个qemu模拟器,两个环境放在同一个局域网中,这样虽然不是真实的物理环境,但是对于我们这里实验的问题来说已经足够了。在这个环境的搭建过程qemu使用tap虚拟网卡接入宿主机环境,并且和宿主机在同一个网段中。下面是具体的环境配置:
1、Linux宿主机的环境配置
tsecer@harry: ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.65.3  netmask 255.255.255.0  broadcast 192.168.65.255
        inet6 fe80::20c:29ff:fe35:e07c  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:35:e0:7c  txqueuelen 0  (Ethernet)
        RX packets 10  bytes 692 (692.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29  bytes 4098 (4.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno16777736: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::20c:29ff:fe35:e07c  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:35:e0:7c  txqueuelen 1000  (Ethernet)
        RX packets 50  bytes 4948 (4.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 484  bytes 42748 (41.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 15  bytes 1530 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 1530 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::ace2:4eff:feea:a26c  prefixlen 64  scopeid 0x20<link>
        ether ae:e2:4e:ea:a2:6c  txqueuelen 100  (Ethernet)
        RX packets 8  bytes 648 (648.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1785 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
这里测试使用的目的IP地址为11.11.11.11,当然这个地址本身没有意义,只要和两者不在同一个局域网即可。为了环境更加准确,在宿主机上配置到11.11.11.11的路由经过qemu虚拟机上的网卡发送,并且开启网卡的抓发功能:
tsecer@harry: route add -net 11.11.11.0 netmask 255.255.255.0 gw 192.168.65.4
tsecer@harry: echo 1 > /proc/sys/net/ipv4/conf/br0/forwarding 
tsecer@harry: route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.65.1    0.0.0.0         UG    0      0        0 br0
11.11.11.0      192.168.65.4    255.255.255.0   UG    0      0        0 br0
192.168.65.0    0.0.0.0         255.255.255.0   U     0      0        0 br0
tsecer@harry: 
2、qemu虚拟机上的配置
虚拟机上进行类似的镜像配置,设置到11.11.11.0网段的路由经过宿主机上的网络地址,并且使能网卡转发功能。
tsecer@qemu: ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
          inet addr:192.168.65.4  Bcast:192.168.65.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:648 (648.0 B)
          Interrupt:11 Base address:0xc000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.255.255.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
三、测试过程
1、测试方法
环境配置之后,从虚拟机上开始通过telnet连接远程主机(当然这样的配置是不会发送外网的),
tsecer@qemu: telnet 11.11.11.11
并且在宿主机上使用tcpdump抓包:
tsecer@harry: tcpdump -i tap0 -v -nn

tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:13:28.074659 IP (tos 0x0, ttl 64, id 23030, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0x499c (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 413284 ecr 0,nop,wscale 4], length 0
13:13:28.074748 IP (tos 0xc0, ttl 64, id 45796, offset 0, flags [none], proto ICMP (1), length 88)
    192.168.65.3 > 192.168.65.4: ICMP redirect 11.11.11.11 to host 192.168.65.4, length 68
IP (tos 0x0, ttl 63, id 23030, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0x499c (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 413284 ecr 0,nop,wscale 4], length 0
13:13:28.074763 IP (tos 0x0, ttl 63, id 23030, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0x499c (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 413284 ecr 0,nop,wscale 4], length 0
13:14:00.159444 IP (tos 0x0, ttl 64, id 23031, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0xcc75 (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 445322 ecr 0,nop,wscale 4], length 0
13:14:00.159576 IP (tos 0xc0, ttl 64, id 45797, offset 0, flags [none], proto ICMP (1), length 88)
    192.168.65.3 > 192.168.65.4: ICMP redirect 11.11.11.11 to host 192.168.65.4, length 68
IP (tos 0x0, ttl 63, id 23031, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0xcc75 (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 445322 ecr 0,nop,wscale 4], length 0
13:14:00.159601 IP (tos 0x0, ttl 63, id 23031, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.65.4.46857 > 11.11.11.11.23: Flags [S], cksum 0xcc75 (correct), seq 3776155125, win 29200, options [mss 1460,sackOK,TS val 445322 ecr 0,nop,wscale 4], length 0
13:14:05.138528 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.65.3 tell 192.168.65.4, length 46
13:14:05.138588 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.65.3 is-at 00:0c:29:35:e0:7c, length 28
^C
8 packets captured
27 packets received by filter
0 packets dropped by kernel
2、测试结果
从测试结果上看,报文的确是递减了TTL之后被转发给了发送源(qemu虚拟机),但是并没有我们期望的再次被A转发出去,也就是这样的路由错误发送源只犯了一次,而不是持续不断的再次发送,就好像刮彩票的时候,看见一个“谢”字就没必要把后面剩下的“谢惠顾”这三个字再刮出来了,说明他是一个知趣的屌丝。
另外中间穿插了一个抢镜的ICMP REDIRECT报文。
四、REDIRECT ICMP的缘由
1、为什么发送REDIRECT
这个其实比较好理解,假设主机从自己的网口N上收到一个转发报文,查找路由之后发现这个报文要经过网口N再次发送出去,此时主机就会觉得这个报文其实你自己处理可能还会更便捷一点,可能只是发送源不知道这个更短路径而已,所以这个中转主机在中转的同时通过ICMP告诉发送源:你可以通过这个网关来转发,这样会更快一些。
从代码中看,这个路由为
/* called in rcu_read_lock() section */
static int __mkroute_input(struct sk_buff *skb,
  const struct fib_result *res,
  struct in_device *in_dev,
  __be32 daddr, __be32 saddr, u32 tos)
{
……
if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
   (IN_DEV_SHARED_MEDIA(out_dev) ||
    inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) {
flags |= RTCF_DOREDIRECT;
do_cache = false;
}
……
}
然后在转发的时候判断RTCF_DOREDIRECT标志位,在转发前给发送源发送REDIRECT ICMP消息
int ip_forward(struct sk_buff *skb)
{
……

/*
* We now generate an ICMP HOST REDIRECT giving the route
* we calculated.
*/
if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr && !skb_sec_path(skb))
ip_rt_send_redirect(skb);

skb->priority = rt_tos2priority(iph->tos);

return NF_HOOK(NFPROTO_IPV4, NF_INET_FORWARD, skb, skb->dev,
      rt->dst.dev, ip_forward_finish);
……
}
2、发送源对ICMP报文的处理
发送源接收到ICMP报文之后,它查找了下新指定的网关竟然是自己(inet_addr_type(net, new_gw)返回的类型是RTN_LOCAL),这个多少有些震惊,所以默默地拒绝了这个REDIRECT提示。所以这个ICMP并没有避免发送源在错误的道路上越走越远。
static void __ip_do_redirect(struct rtable *rt, struct sk_buff *skb, struct flowi4 *fl4,
    bool kill_route)
{
……
if (inet_addr_type(net, new_gw) != RTN_UNICAST)
goto reject_redirect;
}
五、发送源如何意识到路由的错误
我们回过头来再看下路由函数:当发送源接收到反射回来的转发请求的时候,它同样是继续查询自己的路由表:
static int __mkroute_input(struct sk_buff *skb,
  const struct fib_result *res,
  struct in_device *in_dev,
  __be32 daddr, __be32 saddr, u32 tos)
{
……
err = fib_validate_source(skb, saddr, daddr, tos, FIB_RES_OIF(*res),
 in_dev->dev, in_dev, &itag);
if (err < 0) {
ip_handle_martian_source(in_dev->dev, in_dev, skb, daddr,
saddr);

goto cleanup;
}
……
}
static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
u8 tos, int oif, struct net_device *dev,
int rpf, struct in_device *idev, u32 *itag)
{
int ret, no_addr, accept_local;
struct fib_result res;
struct flowi4 fl4;
struct net *net;
bool dev_match;

fl4.flowi4_oif = 0;
fl4.flowi4_iif = oif;
fl4.daddr = src;
fl4.saddr = dst;
fl4.flowi4_tos = tos;
fl4.flowi4_scope = RT_SCOPE_UNIVERSE;

no_addr = idev->ifa_list == NULL;

accept_local = IN_DEV_ACCEPT_LOCAL(idev);
fl4.flowi4_mark = IN_DEV_SRC_VMARK(idev) ? skb->mark : 0;

net = dev_net(dev);
if (fib_lookup(net, &fl4, &res))
goto last_resort;
if (res.type != RTN_UNICAST) {
if (res.type != RTN_LOCAL || !accept_local)
goto e_inval;
}
……
}
当发送源收到“反射”回来的转发请求的时候,此时它通过__fib_validate_source验证了下发送源的合法性,具体做法就是将报文的目的和源路由调换个儿,以IP源为目的,以IP目的为源,然后在自己本机上查询路由。对于我们这里构造的情况,此时原始报文的IP源就是本机地址,转换为目的之后,fib_lookup返回的res.type值为RTN_LOCAL,所以发送源意识到这里有严重的问题,直接goto e_inval丢弃了这次转发请求,从而避免了这个报文在两个主机中打乒乓。
六、对测试过程使用的虚拟网桥设备的说明
这个虚拟设备是工作在链路层上的虚拟设备,也就是它转发的规则使用的是网络设备的MAC地址,这一点和路由器根据MAC地址路由的规则不同。
1、新网口的添加
br_add_if===>>>br_fdb_insert(br, p, dev->dev_addr, 0)===>>>fdb_insert(br, source, addr, vid)===>>>fdb_create
这里可以看到fdb_insert在添加的时候使用的是设备的MAC地址作为键值,也就是说当添加一个设备到网卡的时候,网桥更关心的是设备的MAC地址,并且根据这个来作为转发的依据。
2、MAC地址的学习
在网桥收到任何一个报文的时候,如果使能了学习模式,会更新自己的MAC地址库(使用收到报文的源地址作为键值,对应到网口),
int br_handle_frame_finish(struct sk_buff *skb)
{
……
if (p->flags & BR_LEARNING)
br_fdb_update(br, p, eth_hdr(skb)->h_source, vid);
3、在需要发送报文时
br_dev_xmit===>>>((dst = __br_fdb_get(br, dest, vid)) != NULL) br_deliver(dst->dst, skb);===>>>__br_deliver===>>>br_forward_finish===>>>br_dev_queue_push_xmit===>>>dev_queue_xmit
其中__br_deliver修改了数据包发送时使用的dev为fdb中查找出的网口信息。
4、网口收到报文时
br_handle_frame===>>>br_handle_frame_finish
} else if ((dst = __br_fdb_get(br, dest, vid)) &&
dst->is_local) {
skb2 = skb;
/* Do not forward the packet since it's local. */
skb = NULL;
}

if (skb) {
if (dst) {
dst->used = jiffies;
br_forward(dst->dst, skb, skb2);
} else
br_flood_forward(br, skb, skb2, unicast);
}

if (skb2)
return br_pass_frame_up(skb2);
5、和路由表的一点类比
这里使用的fdb是forwarding database的缩写,而路由表中fib则是forwarding infomation base 的缩写,本质上一样的,都是根据目的地址来查找路由信息,只不过一个使用的是MAC地址,另一个使用的IP地址而已。
  评论这张
 
阅读(45)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017