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

　　前文我们聊到了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 [flags] [operator] [] ...

　　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的请求访问

　　提示：红框中的部分就表示拒绝源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 } ：表示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 "
 this static server ip is 172.17.0.2 
" > 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 "
 this static server ip is 172.17.0.3 
" > index.html
/usr/local/apache2/htdocs/static # exit
[root@docker_node1 ~]# docker exec -it web3 /bin/sh
/usr/local/apache2 # echo "
 this is app server ip is 172.17.0.4 
" >htdocs/index.html 
/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组上去，实现了动静分离；