透明代理让你轻松上网!反向代理让你安全无忧访问web服务!

本文涉及的产品
云防火墙,500元 1000GB
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介:

  透明代理是NAT和代理的完美结合,之所以称为透明,是因为在这种工作方式下用户感觉不到代理服务器的存在,不需要在浏览器或其他客户端工具(如网络快车等)中作任何设置,客户机只需要将默认网关设置为Linux服务器的IP地址即可。当客户机访问Internet,请求数据包经过Linux服务器转发时,Linux服务器上的iptables将客户机的HTTP请求重定向到Squid代理服务器,由代理服务器代替客户机访问外部信息资源,再将获取的数据传回客户机。

拓扑图:(内网访问外网)

image

设备                      ip地址/子网掩码             网关                       DNS

pc :                    192.168.20.22/24       192.168.20.100       222.85.85.85

服务器:  eth1:  192.168.20.100/24   

                  eth0:  192.168.2.10/24              192.168.2.1

无线AP               192.168.2.1/24

一、准备工作:

1.配ip: setup

image image

网络服务重启并查看网关:

image

2.连接方式:

eth0  VMnet0  Bridged      //桥接到无线路由器直接上网!

eth1  VMnet1  Host-only

image

image

3.pc1(内网主机)作为测试: (windows xp)

image

二、具体配置:

1.开启数据包转发功能!

[root@gjp99 ~]# vim /etc/sysctl.conf

image

[root@gjp99 ~]# sysctl –p   //查看是否已修改成功 
net.ipv4.ip_forward = 1 
net.ipv4.conf.default.rp_filter = 1 
net.ipv4.conf.default.accept_source_route = 0 
kernel.sysrq = 0 
kernel.core_uses_pid = 1 
net.ipv4.tcp_syncookies = 1 
kernel.msgmnb = 65536 
kernel.msgmax = 65536 
kernel.shmmax = 4294967295 
kernel.shmall = 268435456

2.NAT 代替代理实现其功能!

[root@gjp99 ~]# iptables -t nat -L 
Chain PREROUTING (policy ACCEPT) 
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT) 
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT) 
target     prot opt source               destination

[root@gjp99 ~]# iptables -t filter -L 
Chain INPUT (policy ACCEPT) 
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT) 
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT) 
target     prot opt source               destination

在squid机器上设置关于dns的nat转换

[root@gjp99 ~]# iptables -t nat -A POSTROUTING -s 192.168.20.0/24 -p udp --dport 53 -o eth0 -j MASQUERADE

image 

imageimage

[root@gjp99 ~]# iptables -t nat -L -v –n        //查看nat的详细信息! 
Chain PREROUTING (policy ACCEPT 165 packets, 22327 bytes) 
pkts bytes target     prot opt in     out     source               destination     

Chain POSTROUTING (policy ACCEPT 35 packets, 2134 bytes) 
pkts bytes target     prot opt in     out     source               destination         
      251 MASQUERADE  udp  --  *      eth0    192.168.20.0/24      0.0.0.0/0           udp dpt:53

设置端口重定向:

[root@gjp99 ~]# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j REDIRECT --to-ports  3128

3.打开透明传输

[root@gjp99 ~]# vim /etc/squid/squid.confimage

4.客户端访问成功

image

注意:要经过代理服务器访问的主机,在DOS下不能使用ping  、tracert命令,但可以正常上网!

[root@gjp99 ~]# tail -f /var/log/squid/access.log

1346486724.345   1295 192.168.20.22 TCP_MISS/302 928 GET http://www.google.com/ - DIRECT/74.125.128.104 text/html

 反向代理:

简介:

反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。

什么是反向代理呢?

反向代理也就是通常所说的WEB服务器加速,它是一种通过在繁忙的WEB服务器和Internet之间增加一个高速的WEB缓冲服务器(即:WEB反向代理服务器)来降低实际的WEB服务器的负载。

Web服务器加速(反向代理)是针对Web服务器提供加速功能的。它作为代理Cache,但并不针对浏览器用户,而针对一台或多台特定Web服务器(这也是反向代理名称的由来)。实施反向代理,只要将Reverse Proxy Cache设备放置在一台或多台Web服务器前端即可。当互联网用户访问某个WEB服务器时,通过DNS服务器解析后的IP地址是Reverse Proxy Server的IP地址,而非原始Web服务器的IP地址,这时Reverse Proxy Server设备充当Web服务器浏览器可以与它连接,无需再直接与Web服务器相连。因此,大量Web服务工作量被卸载到反向代理服务上。不但能够防止外部网主机直接和web服务器直接通信带来的安全隐患,而且能够很大程度上减轻web服务器的负担,提高访问速度。

1 .反向代理 - 原理

反向代理服务器位于本地WEB服务器和Internet之间。当用户浏览器发出一个HTTP请求时,通过域名解析将请求定向到反向代理服务器(如果要实现多个WEB服务器的反向代理,需要将多个WEB服务器的域名都指向反向代理服务器)。由反向代理服务器处理器请求。反向代理一般只缓存可缓冲的数据(比如html网页和图片等),而一些CGI脚本程序或者ASP之类的程序不缓存。它根据从WEB服务器返回的HTTP头标记来缓冲静态页面。有四个最重要HTTP头标记: 
Last-Modified: 告诉反向代理页面什么时间被修改 
Expires: 告诉反向代理页面什么时间应该从缓冲区中删除 
Cache-Control: 告诉反向代理页面是否应该被缓冲 
Pragma: 告诉反向代理页面是否应该被缓冲. 
例如:在默认情况下,ASP页面返回” Cache-control: private.” ,所以ASP页面时不会在反向代理服务器缓存的

2 .反向代理服务器与内容服务器

代理服务器充当服务器的替身,如果您的内容服务器具有必须保持安全的敏感信息,如信用卡号数据库,可在防火墙外部设置一个代理服务器作为内容服务器的替身。当外部客户机尝试访问内容服务器时,会将其送到代理服务器。实际内容位于内容服务器上,在防火墙内部受到安全保护。代理服务器位于防火墙外部,在客户机看来就像是内容服务器。

客户机向站点提出请求时,请求转到代理服务器。然后,代理服务器通过防火墙中的特定通路,将客户机的请求发送到内容服务器。内容服务器再通过该通道将结果回传给代理服务器。代理服务器将检索到的信息发送给客户机,好像代理服务器就是实际的内容服务器。如果内容服务器返回错误消息,代理服务器会先行截取该消息并更改标头中列出的任何  URL,然后再将消息发送给客户机。如此可防止外部客户机获取内部内容服务器的重定向  URL。

这样,代理服务器就在安全数据库和可能的恶意攻击之间提供了又一道屏障。与有权访问整个数据库的情况相对比,就算是侥幸攻击成功,作恶者充其量也仅限于访问单个事务中所涉及的信息。未经授权的用户无法访问到真正的内容服务器,因为防火墙通路只允许代理服务器有权进行访问。

3. 反向代理服务器的工作流程

1)用户通过域名发出访问 web 服务器的请求,该域名被 DNS 服务器解析为反向代理服务器的 IP地址;

2)反向代理服务器接受用户的请求

3)反向代理服务器在本地缓存中查找请求的内容找到后直接把内容发送给用户

4)如果本地缓存里没有用户所请求的信息内容反向代理服务器会代替用户向源服务器请求同样的信息内容,并把信息内容发给用户,如果信息内容是缓存的还会把它保存到缓存中。

4 .反向代理的好处

1) 解决了网站服务器对外可见的问题;

2) 节约了有限的 IP 地址资源,企业内所有的网站共享一个在 internet 中注册的 IP 地址,这些服务器分配私有地址,采用虚拟主机的方式对外提供服务;

3) 保护了真实的 web 服务器,web 服务器对外不可见,外网只能看到反向代理服务器,而反向代理服务器上并没有真实数据,因此,保证了 web 服务器的资源安全;

拓扑图:(外网访问内网)

image

配置:

代理服务器配置:

[root@gjp99 ~]# vim /etc/squid/squid.conf[root@gjp99 ~]# vim /etc/squid/squid.conf

1.添加访问 ip及端口:

image

2.添加内网服务器ip 及访问端口

image

 

3.默认拒绝所有,要打开允许!

image 

内网web服务器的配置:

    mount 
    mount /dev/cdrom /mnt/cdrom 
    cd /mnt/cdrom/Server 

[root@localhost Server]# ll http* 
-r--r--r-- 55 root root 1270589 2008-12-11 httpd-2.2.3-22.el5.i386.rpm 
-r--r--r-- 63 root root  151651 2008-12-11 httpd-devel-2.2.3-22.el5.i386.rpm

     rpm -ivh httpd-2.2.3-22.el5.i386.rpm

     yum   list  all  |grep http

     yum install httpd-devel-2.2.3-22.el5.i386.rpm

     vim /etc/yum.repos.d/rhel-debuginfo.repo 

[root@localhost Server]# cat /etc/yum.repos.d/rhel-debuginfo.repo 
[rhel-server] 
name=Red Hat Enterprise Server 
baseurl=file:///mnt/cdrom/Server 
enabled=1 
gpgcheck=1 
gpgkey=file:///mnt/cdrom/RPM-GPG-KEY-redhat-release 
        cd /var/www/html 
        echo "gjp" >> index.html 
        firefox 
        ll lyn  x-2.8.5-28.1.el5_2.1.i386.rpm  
        rpm -ivh lynx-2.8.5-28.1.el5_2.1.i386.rpm  
        lynx http://127.0.0.1

        service  httpd start

外网,访问192.168.2.10 ,作为测试:

image



本文转自 gjp0731 51CTO博客,原文链接:http://blog.51cto.com/guojiping/980077


相关文章
|
9天前
|
Go UED
Go Web服务中如何优雅平滑重启?
在生产环境中,服务升级时如何确保不中断当前请求并应用新代码是一个挑战。本文介绍了如何使用 Go 语言的 `endless` 包实现服务的优雅重启,确保在不停止服务的情况下完成无缝升级。通过示例代码和测试步骤,详细展示了 `endless` 包的工作原理和实际应用。
25 3
|
9天前
|
JSON Go UED
Go Web服务中如何优雅关机?
在构建 Web 服务时,优雅关机是一个关键的技术点,它确保服务关闭时所有正在处理的请求都能顺利完成。本文通过一个简单的 Go 语言示例,展示了如何使用 Gin 框架实现优雅关机。通过捕获系统信号和使用 `http.Server` 的 `Shutdown` 方法,我们可以在服务关闭前等待所有请求处理完毕,从而提升用户体验,避免数据丢失或不一致。
14 1
|
15天前
|
XML 安全 PHP
PHP与SOAP Web服务开发:基础与进阶教程
本文介绍了PHP与SOAP Web服务的基础和进阶知识,涵盖SOAP的基本概念、PHP中的SoapServer和SoapClient类的使用方法,以及服务端和客户端的开发示例。此外,还探讨了安全性、性能优化等高级主题,帮助开发者掌握更高效的Web服务开发技巧。
|
15天前
|
SQL 负载均衡 安全
安全至上:Web应用防火墙技术深度剖析与实战
【10月更文挑战第29天】在数字化时代,Web应用防火墙(WAF)成为保护Web应用免受攻击的关键技术。本文深入解析WAF的工作原理和核心组件,如Envoy和Coraza,并提供实战指南,涵盖动态加载规则、集成威胁情报、高可用性配置等内容,帮助开发者和安全专家构建更安全的Web环境。
35 1
|
18天前
|
安全 前端开发 Java
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域,本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS,介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF,提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略,开发者可以构建更安全的Web应用。
56 4
|
17天前
|
安全 Go PHP
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS,介绍了输入验证与净化、内容安全策略(CSP)和HTTP头部安全配置;针对CSRF,提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法,帮助开发者有效保护网站和用户数据安全。
45 2
|
19天前
|
存储 安全 Go
Web安全基础:防范XSS与CSRF攻击的方法
【10月更文挑战第25天】Web安全是互联网应用开发中的重要环节。本文通过具体案例分析了跨站脚本攻击(XSS)和跨站请求伪造(CSRF)的原理及防范方法,包括服务器端数据过滤、使用Content Security Policy (CSP)、添加CSRF令牌等措施,帮助开发者构建更安全的Web应用。
51 3
|
19天前
【Azure App Service】PowerShell脚本批量添加IP地址到Web App允许访问IP列表中
Web App取消公网访问后,只允许特定IP能访问Web App。需要写一下段PowerShell脚本,批量添加IP到Web App的允许访问IP列表里!
|
22天前
|
SQL 安全 Go
PHP在Web开发中的安全实践与防范措施###
【10月更文挑战第22天】 本文深入探讨了PHP在Web开发中面临的主要安全挑战,包括SQL注入、XSS攻击、CSRF攻击及文件包含漏洞等,并详细阐述了针对这些风险的有效防范策略。通过具体案例分析,揭示了安全编码的重要性,以及如何结合PHP特性与最佳实践来加固Web应用的安全性。全文旨在为开发者提供实用的安全指南,帮助构建更加安全可靠的PHP Web应用。 ###
32 1
|
1月前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
101 3