NGINX正向代理和反向代理

实验记录

目录

第1章 前言

第2章 HTTP代理

2.1 HTTP正向代理

2.2 HTTP反向代理

2.2.1 基本测试

2.2.2 host效验测试

2.2.3 真实IP透传

2.2.3.1 验证验证场景：$remote_addr;

2.2.3.2 验证验证场景二：$proxy_add_x_forwarded_for;

2.2.3.3 验证验证场景三：ng_http_reali_module

第3章 HTTPS代理

3.1 HTTPS 正向代理

3.1.1 SNI代理

3.1.2 CONNECT代理

3.1.3.1 创建需要代理访问的域名Pool

3.1.3.2 创建SSL SNI代理Policy

3.1.3.3 创建代理VS

3.1.3.4 SNI代理Policy编辑

3.2 HTTPS反向代理

3.2.1 基本测试

3.2.2 服务器再次加密代理

3.2.3 双向认证

3.2.4 单IP多域名HTTPS代理

第4章 TCP/UDP代理

4.1 基本测试

2.2.3.1 验证验证场景：$remote_addr;

        配置proxy_set_header X-real-ip  $remote_addr，NGINX代理会在HTTP报头中插入一个叫X-real-ip的字段，并以访问来源IP作为透传地址写入X-real-ip中。

        参照下图：一二层代理均配置“proxy_set_header X-real-ip  $remote_addr;”

        测试验证：

        在二层代理服务器抓取请求报文，查看HTTP报文，可以看到由一层代理填加的X-real-ip字段，其IP地址为客户端实际地址：192.168.101.5。

        在Web服务器抓取请求报文，查看HTTP报文，可以看到二层代理修改后的的X-real-ip字段，其IP地址为一层代理请求地址：192.168.101.52。

        同时测试发现X-real-ip字符其实是可以自定义的，参照下图，将一层代理X-real-ip更改为Hu-xiaotao，二层代理保持不变，并生效。

        再次在二层代理服务器抓取请求报文，查看HTTP报文，二层代理HTTP报头已经变为Hu-xiaotao。

        再次在Web服务器抓取请求报文，查看HTTP报文，可以同时看到一层代理添加的Hu-xiaotao字段和二层代理添加的X-real-ip字段。

        将一二层代理X-real-ip更改为X-Forwarded-For，并生效。

        得到的结果同上

        二层代理服务器抓取请求报文

        Web服务器抓取请求报文

2.2.3.2 验证验证场景二：$proxy_add_x_forwarded_for;

        配置proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for，NGINX代理会在HTTP报头中插入一个叫X-Forwarded-For 的字段，并以访问来源IP作为透传地址写入X-Forwarded-For中，并且为持续增加模式，即每层代理服务器均添加自己的访问来源来IP，对上层代理添加的已经存在IP不做替换操作。

        参照下图：一二层代理均配置“proxy_set_header X-real-ip  $proxy_add_x_forwarded_for;”

        测试验证：

        在二层代理服务器抓取请求报文，查看HTTP报文，可以看到由一层代理填加的X-Forwarded-For字段，其IP地址为客户端实际地址：192.168.101.5。

        在Web服务器抓取请求报文，查看HTTP报文，可以看到二层代理继续添加后的X-Forwarded-For字段，其IP地址为一层代理请求地址：192.168.101.5，192.168.101.52。

2.2.3.3 验证验证场景三：ng_http_reali_module

        在很多场景下，我们的应用可能会经过多层代理，如CDN、SSL卸载、负载均衡等等，这些代理如果都开启x-forwarded-for功能，那么x-forwarded-for字段中会存在着多个IP地址，这可能会导致内部或者WAF等安全设备或者应用本身无法识别真到真正的用户请求访问。

        当然在多级代理的场景下，最简单的方式就是只启用一级代理的x-forwarded-for功能，但是在实际的应用中，可能因为各种原因无法实现这一要求，这时可以采用ng_http_real_module模块对x-forwarded-for的字段进行过滤，以实现真正的客户端IP地址透传功能。

        为更好的测试验证，我们参照下图设置三层代理模式。

        测试验证：

        在一层代理和二层代理启用x-forwarded-for功能，三层代理采用默认配置，在web服务器上分别查看日志和抓取数据包查看，可以看到一二层代理分别插入的x-forwarded-for的IP地址。

        在三层代理配置ng_http_real_module功能

        三层代理配置完成后，在web服务器上分别查看日志和抓取数据包查看，只能看到的真正的客户端的IP地址，并且仅有这一个IP地址，其它代理的IP地址已经被过滤。

第3章 HTTPS代理

        HTTPS由于其内容为加密流量，客户端访问内容代理服务器不可见，可采用SNI代理和CONNECT代理。

        其中SNI代理NGINX-OSS和NGINX-Plus均由官方模块支持，CONNECT代理由第三方模块支持，NGINX-OSS可支持，NGINX-Plus无法支持。

3.1 HTTPS 正向代理

3.1.1 SNI代理

        SNI代理采用四层模式，使用“ngx_stream_ssl_preread_module”模块，其原理通过识别客户端的SNI信息中的请求域名后再进行加密的流量的代理转发。

        SNI (Server Name Indication)是用来改善服务器与客户端 SSL (Secure Socket Layer)和 TLS (Transport Layer Security) 的一个扩展，SNI的TLS扩展通过发送请示服务器的域名做为TSL协商的一部分，在Client Hello阶段，通过SNI扩展，将域名信息提前告诉服务器，服务器根据域名取得对应的证书返回给客户端完成校验过程，下图为Client Hello包中的SNI字段，可以看到客户端请示的Server Name为：www.163.com。

        SNI代理完全依赖于客户端在SSL协商过程的SNI信息，如果客户端不支持或者未发送SNI字段信息，则SNI代理将会失败。

        配置示例如下：

测试验证：

修改测试终端的host文件，将网易、百度的主页host解析设置为NGINX代理服务器地址，并使用浏览器正常访问163和百度首页，访问成功，并能查看到浏览器实际访问的IP地址为NGINX代理服务器地址。

3.1.2 CONNECT代理

        CONNECT代理NGINX官方模块不支持， 需要采用第三方模块“ngx_http_proxy_connect_module”实现，其github地址如下：

        https://github.com/chobits/ngx_http_proxy_connect_module

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

1、客户端给代理服务器发送HTTP CONNECT请求。

2、代理服务器利用HTTP CONNECT请求中的主机和端口与目的服务器建立TCP连接。

3、代理服务器给客户端返回HTTP 200响应。

4、客户端和代理服务器建立起HTTP CONNECT隧道，HTTPS流量到达代理服务器后，直接通过TCP透传给远端目的服务器。代理服务器的角色是透传HTTPS流量，并不需要解密HTTPS。

        配置示例如下：

        由于“ngx_http_proxy_connect_module”为第三方模块，在使用之前需要重新编译安装。

        编译安装完成后，即可使用，参照下图，基本配置后，即可进行使用。

测试验证：

设置客户端代理访问，并使用浏览器正常访问163和百度首页，访问成功，并能查看到浏览器实际访问的IP地址为NGINX代理服务器地址。

3.2 HTTPS反向代理

        HTTPS的反向代理即是咱们通常所说的的SSL卸载功能。

3.2.1 基本测试

        配置示例如下:

1、现代兼容性

        对于不需要向后兼容性的服务。 此配置与 Windows 7，Edge，Opera 17，Safari 9，Android 5.0 和 Java 8 上的 Firefox 27，Chrome 30，IE 11 兼容。

        配置参数如下：

        listen 443 ssl http2;

        ssl_protocols TLSv1.2;

        ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;

2、中级兼容性（默认）

        对于不需要与旧客户端（主要是 WinXP）兼容但仍需要支持各种客户端的服务，建议使用此配置。 它与 Firefox 1，Chrome 1，IE 7，Opera 5 和 Safari 1 兼容。（推荐）

        listen 443 ssl http2;

        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

        ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;

3、旧的向后兼容性

        这是旧的密码组件，它主要工作在 Windows XP / IE6 中，如果不是特别需要，建议放弃此配置。

        listen 443 ssl http2;

        ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3;

ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP;

3.2.2 服务器再次加密代理

3.2.3 双向认证

        我们平时使用的HTTPS代理通常采用单向认证方式，即客户端验证通过服务端返回的信息验证服务器的合法性，双向认证则是客户端需要认证服务端以外，还增加了服务端对客户端的认证。

3.2.4 单IP多域名HTTPS代理

        在许多负载均衡上要实现单IP多域名的配置比较麻烦，在NGINX上就特点简单了，新建一个server就可以了，采用server_name区分不同域名。

。

第4章 TCP/UDP代理

        NGINX通过stream模块提供TCP/UDP代理。

4.1 基本测试

        配置示例如下：