当前位置: 移动技术网 > 科技>操作系统>Linux > 负载均衡服务之HAProxy访问控制ACL

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

2020年05月03日  | 移动技术网科技  | 我要评论

  前文我们聊到了haproxy的错误页的配置,自定义日志的配置,回顾请参考;今天我们主要来看看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的说明可以参考官方文档;

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

  提示:红框中的部分就表示拒绝源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的客户端访问,看看是否能够实现拒绝访问?

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

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

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

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

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

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

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

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

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

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

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

  提示:可以看到在源地址为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的访问

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

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

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

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

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

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

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

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

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

  示例:利用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>" > 
/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>" > 
/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/ 
/usr/local/apache2 # exit
[root@docker_node1 ~]# 

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

  提示:可以看到我们访问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组上去,实现了动静分离;

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网