负载均衡服务之HAProxy访问控制ACL

技术分享4年前 (2020)更新 技术分享
2,129 0 0

  前文我们聊到了haproxy的错误页的配置,自定义日志的配置,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/12797913.html;今天我们主要来看看haproxy的访问控制的实现;

  ACL(access control list)翻译过来就是访问控制列表;相信ACL这个词对大家都不是太陌生;Linux里的权限里有ACL,httpd、nginx、varnish里都有ACL的概念;访问控制列表(ACL)的使用提供了一个灵活的解决方案来执行内容切换,并通常根据从请求、响应或任何环境状态提取的内容做出决策。haproxy中访问控制实现和httpd、nginx、varnish中的访问控制类似,都是先扑捉用户的请求报文或响应报文,或者其他环境状态的信息来把客户端分类;然后把该ACL作为条件判断,把不同类别或者说符合我们定义ACL的客户端做其他操作;比如我们可以去扑捉用户的请求报文中的referer首部的信息,来判断本次请求的客户端是不是合法的客户端,合法就允许访问,不合法就拒绝访问或重定向到别的url上;至于是不是合法的客户端,这个需要我们明确的去定义acl实现;

  在haproxy中ACL的定义语法如下:

  acl <aclname> <criterion> [flags] [operator] [<value>] …

  acl是关键字,aclname是区别不同acl的标识;不同名称的acl是通过名称来区分的,相同名称的acl表示同一个ACL;criterion表示判断的基准,什么意思呢,就是以criterion指定的信息来分类不同客户端;flages表示标记,常用的标记有 -i表示去区分字符大小写;-m表示使用特定模式匹配方法;-n表示禁用DNS解析;-u表示强制ACL的唯一id;operator表示操作符,常用的操作符有;对于整数值的操作符有 eq(等于)、ge(大于等于)、gt(大于)、le(小于等于)、lt(小于);对于字符串的操作符有,精准匹配 -m str;子串匹配 -m sub;前缀匹配 -m beg;后缀匹配 -m end; 路径匹配 -m dir ;域名匹配 -m dom;value就表示criterion的值,值得类型有布尔型,整数型,IP ,string,正则表达式,十六进制数;

  acl作为条件时的逻辑关系:

  AND 表示与关系;表示满足第一个acl的同时要满足第二acl 此条件才为真;通常用空白字符分隔两个ACL

  OR表示与关系;表示满足acl1或acl2中的任意一个此条件就为真;通常用“||”分隔两个ACL

  !表示非关系;表示对该ACL取相反的操作,意思就是非该acl此条件为真;

  常用的criterion有:

  dst:表示目标ip

  src:表示源ip

  dst_port:表示目标端口

  src_port:表示源端口

  path:表示提取请求的URL路径,该路径从第一个斜杠开始,在问号之前结束(不包括主机部分)。

  url:表示提取请求的整个URL路径;

  req.hdr:表示提取用户请求报文中特定首部;

  status:表示提取响应的状态码;

更多haproxyACL中criterion的说明可以参考官方文档http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#7

  示例:拒绝源ip为192.168.0.21的请求访问

负载均衡服务之HAProxy访问控制ACL

  提示:红框中的部分就表示拒绝源IP为192.168.0.21的访问;acl block_ip src 192.168.0.21表示定义一个acl,名称为block_ip  ,提取客户端的源ip作为分类基准,其源ip的值为192.168.0.21;这意味着只要是源IP为192.168.0.21就会被该acl匹配,或者说源IP为192.168.0.21的请求满足block_ip这个ACL;block if block_ip表示拒绝满足block_ip这条ACL规则的请求;

  测试:用源地址为192.168.0.21的客户端访问,看看是否能够实现拒绝访问?

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到用192.168.0.21为源ip的客户端去访问,给我们返回的是自定义错误页面;这意味着我们本次访问是被拒绝的;

  block { if | unless } <condition>:表示7层拒绝,满足或不满足指定条件就拒绝;

  示例:拒绝用户请求首部User-Agent首部中的包含curl的访问

负载均衡服务之HAProxy访问控制ACL

  提示:红框中的内容表示定义一个acl其名称为block_curl 提取用户请求报文中的User-Agent首部的值做字串匹配,匹配不区分字符大小写,如果用户请求报文中包含curl子串,就表示满足我们定义的ACL,如果满足我们定义的block_curl规则,就拒绝;

  测试:用curl访问192.168.0.22看看是否能够访问?

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到我们用curl去访问是被拒绝的,但是用wget去访问就完全正常,说明我们定义的acl用curl去访问是满足该acl,所以被拒绝了;

  示例:拒绝源地址为192.168.0.21并且User-Agent首部中包含curl字串的客户端访问

负载均衡服务之HAProxy访问控制ACL

  提示:以上配置表示拒绝源地址为192.168.0.21并且用curl访问的客户端请求;

  测试:源地址非192.168.0.21的客户端,用curl访问看看是否能够访问?

负载均衡服务之HAProxy访问控制ACL

  提示:源地址不是192.168.0.21,用curl访问时可以正常访问的;

  测试:源地址为192.168.0.21,用wget访问看看是否可以访问?

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到在源地址为192.168.0.21上用wget可以访问访问,用curl就不能访问,这是因为在源地址为192.168.0.21上用curl访问满足我们定义的两台acl规则,所以就会被拒绝;事实上block_ip 和block_curl这两条ACL是逻辑与的关系,表示两个ACL都要被满足才能拒绝;满足其中一个就不能被拒绝的;

  示例:拒绝源地址为192.168.0.21的访问或者请求报文User-Agent首部的值包含curl的访问

负载均衡服务之HAProxy访问控制ACL

  提示:以上配置就表示满足block_ip 或者block_curl中的任意一条ACL就会被拒绝访问

  测试:在源地址为192.168.0.21上访问192.168.0.22,看看是否都会被拒绝?

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到在源地址为192.168.0.21上不管是用curl还是wget都是被拒绝的,这是因为为被block_ip这条ACL匹配;

  测试:在源地址非192.168.0.21上用curl和wget访问,看看会是什么情况?

负载均衡服务之HAProxy访问控制ACL

  提示:提示可以看到在非192.168.0.21为源地址的主机上用curl访问时,就会被拒绝,用wget访问就完全正常,这是因为用curl访问会被block_curl这条ACL匹配,所以会被拒绝访问;而用wget不会匹配到任何一条ACL,所以访问就不会受限制;ACL作为条件或关系只需要满足其中一条ACL即可;

  示例:拒绝referer首部包含test的域名字串的访问

负载均衡服务之HAProxy访问控制ACL

  提示:以上配置表示拒绝referer首部包含test的域名字串的访问;其中hdr_dom(referer)同hdr(referer) -m dom是一样的;

  测试:用curl命令模拟referer信息为“www.test.com” 看看是否能够访问?

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到在不加referer信息的访问时会被拒绝,这是因为请求报文中referer首部的值为空,不满足vaild_referer这条ACL,所以!valid_referer就为真,所以会被拒绝;加上referer访问就会被valid_referer匹配,!valid_referer就为假,所以访问就不会被拒绝;

  示例:利用ACL实现动静分离

负载均衡服务之HAProxy访问控制ACL

  提示:以上配置表示不区分字符大小写匹配用户请求的URI路径中以/static /images /javascript /stylesheets开头或者以.jpg .gif .png .css .js .html .txt .htm结尾的请求都归类于url_static这个ACL中(以上是两条同名的ACL,它俩会被haproxy识别成一条ACL,即两条ACL之间是或关系,表示满足其中一条即可);如果用户请求的URI路径满足定义的ACL,就把请求调度到static_servs这个后端组响应;不满足就默认调度到appservs这个后端组上进行响应;

  实验环境说明,本人以三台容器模拟static服务器和app服务器;分别在web1和web2上新建static目录并在对应目录下新建一主页,内容是写明是static服务器,ip地址是多少,这样的方式区分;在web3上修改主页内容为app server ip 是172.17.0.4;

[root@docker_node1 ~]# docker exec -it web1 /bin/sh
/usr/local/apache2 # cd htdocs/
/usr/local/apache2/htdocs # mkdir static
/usr/local/apache2/htdocs # cd static/
/usr/local/apache2/htdocs/static # echo "<h1> this static server ip is 172.17.0.2 </h1>" > index.html
/usr/local/apache2/htdocs/static # exit
[root@docker_node1 ~]# docker exec -it web2 /bin/sh
/usr/local/apache2 # cd htdocs/
/usr/local/apache2/htdocs # mkdir static
/usr/local/apache2/htdocs # cd static
/usr/local/apache2/htdocs/static # echo "<h1> this static server ip is 172.17.0.3 </h1>" > index.html
/usr/local/apache2/htdocs/static # exit
[root@docker_node1 ~]# docker exec -it web3 /bin/sh
/usr/local/apache2 # echo "<h1> this is app server ip is 172.17.0.4 </h1>" >htdocs/index.html 
/usr/local/apache2 # exit
[root@docker_node1 ~]# 

  测试:重启haproxy,然后访问192.168.0.22/static/ 和访问192.168.0.22看看有什么区别

负载均衡服务之HAProxy访问控制ACL

  提示:可以看到我们访问192.168.0.22就只会把请求调度到172.17.0.4这台容器响应,这是因为请求URI路径不被url_static这条ACL匹配,所以就默认走default_backend 指定的server组;访问/static时被url_static这条ACL匹配,所以会把访问/static的请求发送给use_backend指定的server组;这样一来我们就通过不同的URI路径把用户请求调度到不同的后端server组上去,实现了动态分离;

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...