Apache正向代理与反向代理

本节索引


  • 场景分析
  • 正向代理
  • 反向代理
  • ProxyPass与ProxyPassServer
  • 搭建实验环境
  • 测试分析
  • 本篇小结

场景分析


        通常的代理服务器,只用于代理内部网络对Internet的连接请求,客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器,普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器,因此普通的Web代理服务器不支持外部对内部网络的访问请求当一个代理服务器能够代理外部网络上的主机,访问内部网络时,这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器,外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于,这个服务器没有保存任何网页的真实数据,所有的静态网页或者CGI程序,都保存在内部的Web服务器上因此对反向代理服务器的攻击并不会使得网页信息遭到破坏,这样就增强了Web服务器的安全性。

        反向代理方式和包过滤方式或普通代理方式并无冲突,因此可以在防火墙设备中同时使用这两种方式,其中反向代理用于外部网络访问内部网络时使用,正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以结合这些方式提供最佳的安全访问方式

正向代理

        正向代理主要是将内网的访问请求通过代理服务器转发访问并返回结果。通常客户端无法直接访问外部的web,需要在客户端所在的网络内架设一台代理服务器,客户端通过代理服务器访问外部的web,需要在客户端的浏览器中设置代理服务器。一般由两个使用场景;

        场景1:局域网的代理服务器;

        场景2:访问某个受限网络的代理服务器,如访问某些国外网站。正向代理的原理图如下:

wKiom1nQvJvyOiRHAABfLbaNIhQ441.png

反向代理


        客户端能访问外部的web,但是不能访问某些局域网中的web站点,此时我们需要目标网络中的一台主机做反向代理服务器来充当我们的访问目标,将局域网内部的web等站点资源缓存到代理服务器上,,客户端直接访问代理就像访问目标web一样(此代理对客户端透明,即客户端不用做如何设置,并不知道实际访问的只是代理而已,以为就是访问的目标)一般使用场景是:

        场景1:idc的某台目标机器只对内开放web,外部的客户端要访问,就让另一台机器做proxy,外部直接访问proxy即相当于访问目标;

        场景2:idc的目标机器的某个特殊的web服务工作在非正常端口如8080,而防火墙上只对外开放了80,此时可在80上做proxy映射到8080,外部访问80即相当于8080。方向代理的原理图如下:

wKioL1nQvGOC7pJoAABlKiLmEks752.png

 

ProxyPass与ProxyPassServer


        apache中的mod_proxy模块主要作用就是进行url的转发,即具有代理的功能。应用此功能,可以很方便的实现同tomcat等应用服务器的整合,甚者可以很方便的实现web集群的功能。

1 ProxyPass

    语法:ProxyPass [path] !|url

    说明:它主要是用作URL前缀匹配,不能有正则表达式,它里面配置的Path实际上是一个虚拟的路径,在反向代理到后端的url后,path是不会带过去的,使用示例:

        1)ProxyPass / images/  !   这个示例表示,/images/的请求不被转发。

        2)ProxyPass /mirror/foo/ http://backend.example.com/  我们假设当前的服务地址是http://example.com/,如果我们做下面这样的请求:http://example.com/mirror/foo/bar那将被转成内部请求:http://backend.example.com/bar

    注意:配置的时候,不需要被转发的请求,要配置在需要被转发的请求前面。

2 ProxyPassMatch

    语法:ProxyPassMatch [regex] !|url

    说明:这个实际上是url正则匹配,而不是简单的前缀匹配,匹配上的regex部分是会带到后端的url的,这个是与ProxyPass不同的。使用示例:

        1) ProxyPassMatch ^/images !  这个示例表示对/images的请求,都不会被转发。

3 ProxyPassReverse

    语法:ProxyPassReverse [路径] url

    说明:它一般和ProxyPass指令配合使用,此指令使Apache调整HTTP重定向应答中Location, Content-Location, URI头里的URL,这样可以避免在Apache作为反向代理使用时。后端服务器的HTTP重定向造成的绕过反向代理的问题。参看下面的例子:

实验环境搭建


        上面介绍了ProxyPass与ProxyPassServer以及ProxyPassMatch的基础用法,下面详解向大家解释他们的工作原理。

    1)实验前准备

        准备三台虚拟机,一台主机充当代理服务器,一台主机当web服务器,一台主机作为客户端使用。为了实验的方便,我们关闭三台主机的防火墙与SELINUX,并安装http服务包。

wKiom1nQykPzbL84AAAY9o_aP00445.png

[root@linuxidc ~] # iptables -F             # 关闭防火墙
[root@linuxidc ~] # setenforce 0            # 临时关闭selinux
[root@linuxidc ~] # sed -i 's/^SELINUX=.*$/SELINUX=disabled/' /etc/selinux/config #永久关闭
[root@linuxidc ~] #

    2)配置代理服务器

        代理服务器主要是实现对客户端的访问进行转发,去web服务器上替客户端访问资源。

wKioL1nQzLCAUc8qAAAla_v-hLc227.png

    3)配置web服务器

        在web服务器上配置虚拟主机并设置redirect参数,由于ProxyPassServer只有在出现302转发是才能体现出它与ProxyPass不同。为了模拟局域网环境,我们使用防火墙策略禁用客户端的访问。

wKioL1nQzMPz1lOVAABhR4Uj0Lo014.png

 

结果分析


        上面搭建好了代理服务器,接下来配合是elinks与tcpdump以及wireshark我们来做实验分析(这里主要是验证ProxyPassServer的作用,ProxyPass原理简单,这里不做实验证明)。

测试1:我们不开启ProxyPassServer选项,只使用ProxyPass选项。如下图

[root@linuxidc ~] #cat  /etc/httpd/conf.d/test.conf
<VirtualHost *:80>
    ProxyPass  "/"  "http://172.18.254.54/"       
    #ProxyPassReverse "/" "     # 注释掉 
< /VirtualHost >

    在客户端上使用elinks访问代理服务器。

[root@linuxidc ~] #elinks http://172.18.250.234/index.html.txt

由于没有ProxyPassServer选项,所以我们访问资源失败,出现下图提示。

wKiom1nQ7uqyaKkHAAAVO6nZvk0199.png

测试2:开启ProxyPassServer选项,我么先在Agent上开启tcpdump进行抓包

[root@linuxidc ~] # tcpdump tcp -i ens33 -w ./target.cap     # -w 表示将结果存储起来,方便wireshark进行分析

    在客户端上使用elinks进行访问,为了验证ProxyPassServer的功能我们访问两次。由于使用了ProxyPassServer功能,所以我们能看到重定向的文件内容。

wKioL1nQ1ZOQTArTAAATeGu0wIU763.png

    然后我们分析一下抓到的数据包。

wKiom1nQ1cXRMUIBAABKtqoQUgc867.png

    从上面的数据包信息可知当我们第一次访问index.html.txt时,由于index.html.txt重定向到了inde2.html,所以代理服务器在返回结果是,不是返回给客户端一个重定向后的资源(http://172.18.254.54/inde2.html),这个资源对客户端是不能访问的,此时ProxyPassServer的作用就起作用了,代理服务器在返回该资源时,直接又去访问了重定向之后的资源,然后在返回给客户端数据。也验证了上文中提到的ProxyPassServer的工作原理。

本篇总结


        记得第一次看到这个两个参数的时候,也是一脸茫然,经过简单的实验发现,有没有ProxyPassServer参数都能访问成功,后来查找了许多资料,发现如果出现重定向(301、302)资源的情况下(目前我只发现这种时候会有区别,是不是唯一,我不敢说),客户端在去访问资源便不可以。于是亲手实验,发现果然如此,当添加ProxyPassServer参数后,访问重定向资源也能顺利访问了。由于实验需要很多的测试,一会儿在这台机器,一会儿在另外一台主机上,文章中为了能让大家能够很好的理解,有些小细节就省略了。实验步骤太多,所以绞尽脑汁也没有完美的描述出实验过程,望读者见谅。

猜你喜欢

转载自www.linuxidc.com/Linux/2017-10/147378.htm