zoukankan      html  css  js  c++  java
  • TCP/IP卷一没提到的策略路由

    策略路由

    tcp/ip书上介绍了选路和动态路由,没有提及策略路由,应该是因为那个年代还不存在策略路由吧,但是这是个很有用的东西。

    背景

    昨天领导做了一个虚拟机,里面配了两个网络172.16.50.33和172.16.40.33,从办公网络访问过去,如果发现同时只有一个网卡能通,正好在学网络最近,我就帮着看一看,然后发现,除了静态路由之外,还有策略路由,直通路由,虫洞路由各种乱七八糟的路由概念。

    问题

    网卡eth0,ip 172.16.50.33
    网卡eth1,ip 172.16.40.33

    当网卡eth0 up,eth1 down时,eth0可以连通
    当网卡eth1 up,eth0 down时,eth1可以连通

    当网卡eth0和em1都up时,只有后up的网卡可以连通。

    当两个网卡都up时,观察到路由表如下

    [root@zhangyufei-net-test ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
    172.16.40.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
    0.0.0.0         172.16.50.1     0.0.0.0         UG    0      0        0 eth0
    

    这三台路由规则的含义分别是:

    1. 如果目的IP地址在172.16.50/24段,则网关地址为0.0.0.0,说明目的地址和eth0链路层直接相连,没有网络层的下一跳,我们直接arp请求目的地址的mac地址,如果获得,就将链路层目的地址设置成该mac地址,讲数据包从eth0发出
    2. 如果目的IP地址在172.16.40/24段,则网关地址为0.0.0.0,说明目的地址和eth1链路层直接相连,没有网络层的下一跳,我们直接arp请求目的地址的mac地址,如果获得,就将链路层目的地址设置成该mac地址,讲数据包从eth1发出
    3. 如果ip地址匹配0.0.0.0/0(任意ip地址都匹配),则网关地址为172.16.50.1,我们将数据包的链路层目的地址设置成172.16.50.1的mac地址,将数据包从eth0发出

    这个时候:

    • 从172.16.40.0/24段的其他主机上可以ping通172.16.40.33
    • 从172.16.50.0/24段的其他主机上可以ping通172.16.50.33
    • 从172.16.2.0/24上ping40.33和50.33,只有50.33可以连通

    如果这时候我执行ifdown eth1;ifup eth1,路由会变成下面的情况:

    [root@zhangyufei-net-test ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
    172.16.40.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
    0.0.0.0         172.16.40.1     0.0.0.0         UG    0      0        0 eth0
    

    这个时候从172.16.2.0/24上ping40.33和50.33,只有172.16.40.33可以连通,观察路由的变换,我们基本可以定位到,问题是在于:网卡eth1启动时候会修改静态路由表,将默认网关修改为172.16.40.1,这样172.16.50.0/24段的主机还能连通172.16.50.33,但是从172.16.2.0/24就不行,因为它访问时需要经过网关,回应时也需要经过网关,但是却已经没有回去的路由告诉他要将数据包发送给172.16.50.1。

    我们tcpdump验证下我们的观点,尝试从第三个网络ping 172.16.50.33,在本机上tcpdump -i eth0 icmp,会观察到下面的输出:

    [root@zhangyufei-net-test ~]# tcpdump -i eth0 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    11:35:06.637135 IP 172.16.2.46 > 172.16.50.33: ICMP echo request, id 63030, seq 52, length 64
    11:35:09.648051 IP 172.16.2.46 > 172.16.50.33: ICMP echo request, id 63030, seq 55, length 64
    11:35:10.649198 IP 172.16.2.46 > 172.16.50.33: ICMP echo request, id 63030, seq 56, length 64
    11:35:11.654530 IP 172.16.2.46 > 172.16.50.33: ICMP echo request, id 63030, seq 57, length 64
    

    可以看到,该网卡能够能够收到icmp request请求,之所以不能响应,就是因为找不到合适的路由从eth0发包给目的地址172.16.2.46。

    策略路由

    问题的关键在于,我们对同一个目的地址,当我们有多条路径可以达到该目的地址时,我们希望路由能够根据源地址来选择不同的网关,默认路由表是做不到这个的,还好谷歌告诉我,有策略路由这个东西,可以做更强大的路由匹配工作。

    在策略路由中,我们有多路由表和规则的概念:

    多路由表(multiple Routing Tables)
      传统的路由算法是仅使用一张路由表的。但是在有些情形底下,我们是需要使用多路由表的。例如一个子网通过一个路由器与外界相连,路由器与外界有两条线路相连,其中一条的速度比较快,一条的速度比较慢。对于子网内的大多数用户来说对速度并没有特殊的要求,所以可以让他们用比较慢的路由;但是子网内有一些特殊的用户却是对速度的要求比较苛刻,所以他们需要使用速度比较快的路由。如果使用一张路由表上述要求是无法实现的,而如果根据源地址或其它参数,对不同的用户使用不同的路由表,这样就可以大大提高路由器的性能。

    规则(rule)
      规则是策略性的关键性的新的概念。我们可以用自然语言这样描述规则,例如我门可以指定这样的规则:  
    规则一:“所有来自192.16.152.24的IP包,使用路由表10, 本规则的优先级别是1500”
    规则二:“所有的包,使用路由表253,本规则的优先级别是32767”
    我们可以看到,规则包含3个要素:
      什么样的包,将应用本规则(所谓的SELECTOR,可能是filter更能反映其作用);
      符合本规则的包将对其采取什么动作(ACTION),例如用那个表;
      本规则的优先级别。优先级别越高的规则越先匹配(数值越小优先级别越高)。

    按照这样的概念,我们在现在这一的情况下:默认网关是172.16.40.1,172.16.50段无法连通。我们需要先创建一个路由表,为这个路由表添加一条路由,默认网关是172.16.50.1,然后再添加一条规则,对所有源地址是172.16.50.33的数据包应用该路由表。

    不过我们还是先看看默认的路由表,一个默认的多路由表是这样的:

    [root@zhangyufei-net-test ~]# cat /etc/iproute2/rt_tables
    #
    # reserved values
    #
    255	local
    254	main
    253	default
    0	unspec
    #
    # local
    #
    #1	inr.ruhep
    

    我们来看下local表中的路由规则:

    broadcast 172.16.50.255 dev eth0  proto kernel  scope link  src 172.16.50.33
    broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
    broadcast 172.16.40.255 dev eth1  proto kernel  scope link  src 172.16.40.33
    broadcast 172.16.50.0 dev eth0  proto kernel  scope link  src 172.16.50.33
    local 172.16.50.33 dev eth0  proto kernel  scope host  src 172.16.50.33
    local 172.16.40.33 dev eth1  proto kernel  scope host  src 172.16.40.33
    broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
    broadcast 172.16.40.0 dev eth1  proto kernel  scope link  src 172.16.40.33
    local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
    local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
    

    可以看到这里都是环回地址相关的路由规则

    再来看main中的路由规则:

    [root@zhangyufei-net-test ~]# ip route list table main
    172.16.50.0/24 dev eth0  proto kernel  scope link  src 172.16.50.33
    172.16.40.0/24 dev eth1  proto kernel  scope link  src 172.16.40.33
    default via 172.16.50.1 dev eth0  proto static
    

    这其实和我们的route -n看到的一样的,也就是我们平时最常用的路由表

    路由表default是空的,不知道做什么用的,以后再补充,unspec是所有表的总和,太大了,不再列举。

    看看默认的规则:

    [root@zhangyufei-net-test ~]# ip rule list
    0:	from all lookup local
    32766:	from all lookup main
    32767:	from all lookup default
    

    0,32766,32767都是优先级,数字越小,优先级越高,可以看出,默认情况下,对于所有数据,都先对它应用环回地址的路由表,最后才应用主路由表和default表。

    最后还是给出上面所说的创建路由表,使得172.16.50.X能够连通的命令:

    echo '30 mine'  >> /etc/iproute2/rt_tables
    ip route add default via 172.16.50.1 dev eth0 table mine
    ip rule add from 172.16.50.33 table mine 
    

    最后一条命令最后可以加‘pref $优先级’的参数,如果不加,默认是除了0之外最小的优先级数字减1,按照数字越小,优先级越高的规则。默认保证,环回路由优先级最高,最后添加的路由优先级其次。

    最后还有一点,如果重启网络,路由规则不会丢,但是路由表里面的路由都会丢,这是个坑爹的事情,网上有人解决了,以后再验证吧。

    参考链接:静态路由和策略路由的配置

    这个文章写得挺好的,但是有一点小问题:rt_table中的表的数字仅仅表示表的序号,和优先级没有关系,路由表是没有优先级的,有优先级的是路由策略

    参考链接: 用Linux系统做策略路由

  • 相关阅读:
    队列与双向队列

    linux nohup, jobs, fg, tail指令 指令前后台切换
    linux shell
    Linux学习笔记四 grep, sed, awk
    面试要求
    jenkins send files or publish
    mysql导入脚本
    第三方接口调用框架
    pdm文件name与comment互相同步
  • 原文地址:https://www.cnblogs.com/zhangyufei/p/5615669.html
Copyright © 2011-2022 走看看