您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

使用代理服务器(使用代理服务器除了服务器端代理服务器软件需配置外)

客户端,代理服务器,目的使用代理服务器(使用代理服务器除了服务器端代理服务器软件需配置外)

发布时间：2016-12-08加入收藏来源：互联网点击：

很多朋友想了解关于使用代理服务器的一些资料信息，下面是小编整理的与使用代理服务器相关的内容分享给大家，一起来看看吧。

NGINX主要设计作为反向代理服务器，但随着NGINX的发展，它同样能作为正向代理的选项之一。正向代理本身并不复杂，而如何代理加密的HTTPS流量是正向代理需要解决的主要问题。本文将介绍利用NGINX来正向代理HTTPS流量两种方案，及其使用场景和主要问题。

HTTP/HTTPS正向代理的分类

简单介绍下正向代理的分类作为理解下文的背景知识：

按客户端有无感知的分类

普通代理：在客户端需要在浏览器中或者系统环境变量手动设置代理的地址和端口。如squid，在客户端指定squid服务器IP和端口3128。透明代理：客户端不需要做任何代理设置，“代理”这个角色对于客户端是透明的。如企业网络链路中的Web Gateway设备。

按代理是否解密HTTPS的分类

隧道代理 ：也就是透传代理。代理服务器只是在TCP协议上透传HTTPS流量，对于其代理的流量的具体内容不解密不感知。客户端和其访问的目的服务器做直接TLS/SSL交互。本文中讨论的NGINX代理方式属于这种模式。中间人(MITM, Man-in-the-Middle)代理：代理服务器解密HTTPS流量，对客户端利用自签名证书完成TLS/SSL握手，对目的服务器端完成正常TLS交互。在客户端-代理-服务器的链路中建立两段TLS/SSL会话。如Charles，简单原理描述可以参考文章。

https://www.jianshu.com/p/405f9d76f8c4

注：这种情况客户端在TLS握手阶段实际上是拿到的代理服务器自己的自签名证书，证书链的验证默认不成功，需要在客户端信任代理自签证书的Root CA证书。所以过程中是客户端有感的。如果要做成无感的透明代理，需要向客户端推送自建的Root CA证书，在企业内部环境下是可实现的。为什么正向代理处理HTTPS流量需要特殊处理？

作为反向代理时，代理服务器通常终结 (terminate) HTTPS加密流量，再转发给后端实例。HTTPS流量的加解密和认证过程发生在客户端和反向代理服务器之间。

而作为正向代理在处理客户端发过来的流量时，HTTP加密封装在了TLS/SSL中，代理服务器无法看到客户端请求URL中想要访问的域名，如下图。所以代理HTTPS流量，相比于HTTP，需要做一些特殊处理。

NGINX的解决方案

根据前文中的分类方式，NGINX解决HTTPS代理的方式都属于透传(隧道)模式，即不解密不感知上层流量。具体的方式有如下7层和4层的两类解决方案。

HTTP CONNECT隧道 (7层解决方案)

历史背景

早在1998年，也就是TLS还没有正式诞生的SSL时代，主导SSL协议的Netscape公司就提出了关于利用web代理来tunneling SSL流量的INTERNET-DRAFT。其核心思想就是利用HTTP CONNECT请求在客户端和代理之间建立一个HTTP CONNECT Tunnel，在CONNECT请求中需要指定客户端需要访问的目的主机和端口。Draft中的原图如下：

整个过程可以参考HTTP权威指南中的图：

客户端给代理服务器发送HTTP CONNECT请求。代理服务器利用HTTP CONNECT请求中的主机和端口与目的服务器建立TCP连接。代理服务器给客户端返回HTTP 200响应。客户端和代理服务器建立起HTTP CONNECT隧道，HTTPS流量到达代理服务器后，直接通过TCP透传给远端目的服务器。代理服务器的角色是透传HTTPS流量，并不需要解密HTTPS。

NGINX ngx_http_proxy_connect_module模块

NGINX作为反向代理服务器，官方一直没有支持HTTP CONNECT方法。但是基于NGINX的模块化、可扩展好的特，阿里的@chobits提供了ngx_http_proxy_connect_module模块，来支持HTTP CONNECT方法，从而让NGINX可以扩展为正向代理。

环境搭建

以CentOS 7的环境为例。

1) 安装

对于新安装的环境，参考正常的安装步骤和安装这个模块的步骤(https://github.com/chobits/ngx_http_proxy_connect_module)，把对应版本的patch打上之后，在configure的时候加上参数--add-module=/path/to/ngx_http_proxy_connect_module，示例如下：

./configure \--user=www \--group=www \--prefix=/usr/local/nginx \--with-http_ssl_module \--with-http_stub_status_module \--with-http_realip_module \--with-threads \--add-module=/root/src/ngx_http_proxy_connect_module

对于已经安装编译安装完的环境，需要加入以上模块，步骤如下：

# 停止NGINX服务# systemctl stop nginx# 备份原执行文件# cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak# 在源代码路径重新编译# cd /usr/local/src/nginx-1.16.0./configure \--user=www \--group=www \--prefix=/usr/local/nginx \--with-http_ssl_module \--with-http_stub_status_module \--with-http_realip_module \--with-threads \--add-module=/root/src/ngx_http_proxy_connect_module# make# 不要make install# 将新生成的可执行文件拷贝覆盖原来的nginx执行文件# cp objs/nginx /usr/local/nginx/sbin/nginx# /usr/bin/nginx -Vnginx version: nginx/1.16.0built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)built with OpenSSL 1.0.2k-fips 26 Jan 2017TLS SNI support enabledconfigure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-threads --add-module=/root/src/ngx_http_proxy_connect_module

2) nginx.conf文件配置

server { listen 443; # dns resolver used by forward proxying resolver 114.114.114.114; # forward proxy for CONNECT request proxy_connect; proxy_connect_allow 443; proxy_connect_connect_timeout 10s; proxy_connect_read_timeout 10s; proxy_connect_send_timeout 10s; # forward proxy for non-CONNECT request location / { proxy_pass http://$host; proxy_set_header Host $host; } }

使用场景

7层需要通过HTTP CONNECT来建立隧道，属于客户端有感知的普通代理方式，需要在客户端手动配置HTTP(S)代理服务器IP和端口。在客户端用curl 加-x参数访问如下：

# curl https://www.baidu.com -svo /dev/null -x 39.105.196.164:443* About to connect() to proxy 39.105.196.164 port 443 (#0)* Trying 39.105.196.164...* Connected to 39.105.196.164 (39.105.196.164) port 443 (#0)* Establish HTTP proxy tunnel to www.baidu.com:443 CONNECT www.baidu.com:443 HTTP/1.1 Host: www.baidu.com:443 User-Agent: curl/7.29.0 Proxy-Connection: Keep-Alive HTTP/1.1 200 Connection Established Proxy-agent: nginx* Proxy replied OK to CONNECT request* Initializing NSS with certpath: sql:/etc/pki/nssdb* CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256* Server certificate:* subject: CN=baidu.com,O="Beijing Baidu Netcom Science Technology Co., Ltd",OU=service operation department,L=beijing,ST=beijing,C=CN... GET / HTTP/1.1 User-Agent: curl/7.29.0 Host: www.baidu.com Accept: */* HTTP/1.1 200 OK...{ [data not shown]

从上面-v参数打印出的细节，可以看到客户端先往代理服务器39.105.196.164建立了HTTP CONNECT隧道，代理回复HTTP/1.1 200 Connection Established后就开始交互TLS/SSL握手和流量了。

NGINX stream (4层解决方案)

既然是使用透传上层流量的方法，那可不可做成“4层代理”，对TCP/UDP以上的协议实现彻底的透传呢？答案是可以的。NGINX官方从1.9.0版本开始支持ngx_stream_core_module模块，模块默认不build，需要configure时加上--with-stream选项来开启。

问题

用NGINX stream在TCP层面上代理HTTPS流量肯定会遇到本文一开始提到的那个问题：代理服务器无法获取客户端想要访问的目的域名。因为在TCP的层面获取的信息仅限于IP和端口层面，没有任何机会拿到域名信息。要拿到目的域名，必须要有拆上层报文获取域名信息的能力，所以NGINX stream的方式不是完全严格意义上的4层代理，还是要略微借助些上层能力。

 1/2    1 2 下一页 尾页