zoukankan      html  css  js  c++  java
  • openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)

    一.写在前面

      唉,被分配到sdn安全方向,顶不住,顶不住,感觉搞不出来什么有搞头的东西。可若是让我水水的应付,我想我也是做不到的,世上无难事只怕有心人。好了,进入正题,本次要讨论的是一个比较细节的东西,在流表项中的有关ip掩码的问题。对了,本文适合于有一定基础的openflow和ryu使用者,一点点就行。

    二、问题描述

      若不是机缘巧合,我甚至完全不会注意到这个问题,为什么,咱来看一个平时实验环境中最为常见的流表项长啥样,如图1

      

                                                               图1 常见的流表项

      当我刚开始学习openflow的时候,我看到的就是这样的流表项,当时我一度以为“喔,这和路由表中的表项是不同的,连掩码都没有,sdn是新型网络的架构设计,应该抛弃了原来的网络架构,可能连掩码都不用使用了”。其实稍微深入想一想就可以发现这个想法根本占不住脚,从实际运用的角度,现在ip网根深蒂固,sdn若想要商业化,必须是要以融入ip网为前提,那么就肯定要考虑在传统网络中具有重大作用的ip掩码了,其次流表项里都有ip地址了,怎么可能不去考虑ip掩码的问题,若不考虑,跨网段通信如何解决?

      直到我在学习ryu防火墙的时候,这个问题的再次出现,才让我恍然大悟,也顺理成章的解决了它。现在来看一下在ryu的防火墙应用中看到的流表项,如图2:

      

                                                             图2 ryuf防火墙中的流表

      有没有觉得流表中的ip地址有些奇怪,对,确实挺奇怪的,但真正奇怪的点在于,这条流表项的产生使用的curl命令为:curl -X POST -d ’{“nw_src”:"10.0.0.1/8","nw_dst:"10.0.0.2/8"}‘ http://localhost:8080/firewall/rules/0000000000000001。没错,你没有看错curl命令中的10.0.0.1/8到达流表项后变为10.0.0.0/8了。先别急这考虑为什么,咱再做个实验,这次curl 的命令为curl -X POST -d curl -X POST -d ’{“nw_src”:"10.0.0.1/32","nw_dst:"10.0.0.2/32"}‘ http://localhost:8080/firewall/rules/0000000000000001,这个curl也是ryu官方文档中的样例,实验后流表项为图3

      

                     图3 ryuf防火墙中的流表

      图3中的流表项和curl中表达的一致,等等图3中的流表项是不是在哪见过?对,和最开始图1中的一样,接下来我们开始根据这三张图的内容进行分析

    三、猜想与实验论证

      首先图3中的实验,我们使用的掩码是32位的,我是从未见过有32位的掩码,所以从这点可以看出这里的掩码与我们常见的路由表中的掩码肯定在概念上是有不同。其次我们再来看这个流表的效果,图1、3可以匹配的仅为源ip为10.0.0.1,目的ip为10.0.0.2的ip,而图2可以匹配的为10.0.0.0整个网段的主机,再考虑这是防火墙的应用,肯定是既需要同时考虑整个网段也需要考虑单独的主机。现在再来看看图2的流表是怎么得到的,curl中写的是10.0.0.1/8 再流表中变为10.0.0.0/8,是不是很像10.0.0.1与255.0.0.0想与得到的结果?

          对,就是这样的,通过查看ryu的源码发现,就是将你所输入的ip源码和掩码做了与操作。在数据包到达ovs之后也是先与掩码做与操作,再和ip匹配。因此如果在防火墙应用阶段如果你想表达整个网段的的ip地址,就是用低于32的掩码即可,也就是说照常用,如果你仅仅只想表达两个主机间的禁止或允许,有两种表达方式,分别就是图1和图3,图1中是在curl中写的“10.0.0.1”,没有写掩码的位数,图3中是在curl中写的“10.0.0.1/32”,写的32位掩码,32位的掩码与任何ip与的结果都是其本身。

      能读到这的都是勇士。到现在不知你心里是否有个疑惑,不管你有没有,反正我是有。疑惑在于图1与图3,图1的curl语句没有写掩码在流表中的效果却和图3中写了32位掩码效果一样,这是不是意味着如果不写掩码,那么默认的掩码就是32位的?

    不是这样的,如何证明这个结论,抓包。wireshark 抓取图1和图3控制器下发的flow-mod信息如图4和图5:使用的curl命令的ip地址分别位10.0.0.0和10.0.0.0/32

                      图4 无掩码的情况

         图5 32位掩码的情况

    从图4和图5可以看出,是有个字段has mask 控制着是否使用掩码,在不使用掩码的时候,也是没有默认掩码这一说法,此时就是精确匹配。比如说在不使用掩码时curl中的ip地址你写的是10.0.0.0,就意味者只能匹配一台ip地址为10.0.0.0的主机,而不是匹配整个网段!

    四、结论

    1.掩码匹配的情况,总体可分为两种,使用掩码或者不使用,不使用掩码,并不是有默认掩码的存在。

    2.在不使用掩码的时候,就是完全精确匹配,IP地址要一摸一样。

    3.使用掩码时,无论是使用curl下发流表还是ovs中的流表匹配都是单纯的ip地址与掩码的与操作,所以会有32掩码的存在,32位的掩码就是想表达单个主机,若想表达网段就使用低于32位的掩码。

  • 相关阅读:
    稳扎稳打Silverlight(47) 4.0UI之操作剪切板, 隐式样式, CompositeTransform, 拖放外部文件到程序中
    返璞归真 asp.net mvc (9) asp.net mvc 3.0 新特性之 View(Razor)
    返璞归真 asp.net mvc (6) asp.net mvc 2.0 新特性
    稳扎稳打Silverlight(48) 4.0其它之打印, 动态绑定, 增强的导航系统, 杂七杂八
    精进不休 .NET 4.0 (9) ADO.NET Entity Framework 4.1 之 Code First
    稳扎稳打Silverlight(42) 4.0控件之Viewbox, RichTextBox
    稳扎稳打Silverlight(53) 4.0通信之对WCF NetTcpBinding的支持, 在Socket通信中通过HTTP检索策略文件, HTTP请求中的ClientHttp和BrowserHttp
    稳扎稳打 Silverlight 4.0 系列文章索引
    稳扎稳打Silverlight(54) 4.0通信之对UDP协议的支持: 通过 UdpAnySourceMulticastClient 实现 ASM(Any Source Multicast),即“任意源多播”
    返璞归真 asp.net mvc (8) asp.net mvc 3.0 新特性之 Model
  • 原文地址:https://www.cnblogs.com/wxrqforever/p/11734905.html
Copyright © 2011-2022 走看看