NGINX技术实践：TCP四层端口代理与mTLS双向加密认证配置指南

25次阅读
没有评论

本文系统拆解 NGINX TCP 四层端口代理与 mTLS 双向加密认证的完整落地方案，从技术原理（TLS/mTLS 核心机制）、证书生成（根 CA / 服务端 / 客户端全流程），到 NGINX 配置（Stream 模块、SSL 参数优化）、功能验证（合法 / 非法连接测试）均附实战命令，助力运维与开发人员快速搭建安全通信通道，解决传统代理架构下的数据泄露、未授权访问等风险，适用于 Redis、数据库等 TCP 服务的加密代理场景。

一、探秘技术背景

在数字化转型进程中，网络安全与高效代理技术已成为现代网络架构的核心组成部分。随着企业业务规模扩张与业务场景复杂化，网络通信面临中间人攻击、数据窃取、信息篡改等多重安全威胁，对通信架构的安全性与可靠性提出了更高要求。

传统网络代理方案在应对复杂安全场景时存在局限性，而 Nginx 作为高性能 HTTP 及反向代理服务器，凭借其稳定性、高效性及丰富功能模块，在代理领域占据重要地位。Nginx 不仅支持 HTTP 协议的七层代理，还可通过 Stream 模块实现 TCP、UDP 协议的四层代理，为网络通信提供灵活且高性能的解决方案。

mTLS 双向认证加密技术是保障网络安全通信的关键手段。传统 TLS 单向认证仅实现客户端对服务器的身份验证，存在攻击者伪装合法服务器窃取数据的风险。mTLS 双向认证要求通信双方均进行身份核验，通过证书验证机制确保双方身份合法性，有效防范中间人攻击与数据泄露，保障数据传输的机密性、完整性与可用性。

在数据敏感型行业中，如金融领域的客户交易信息处理、医疗行业的隐私病历传输、电商平台的用户信息保护等场景，Nginx TCP 四层代理与 mTLS 双向认证的结合应用具有重要意义。该技术组合既满足企业对网络通信性能的需求，又为数据安全提供全方位保障，是企业数字化转型中保障网络架构安全的核心技术支撑。

NGINX 技术实践：TCP 四层端口代理与 mTLS 双向加密认证配置指南

二、NGINX 代理 TCP 四层端口

（一）准备工作

配置 Nginx TCP 四层端口代理前，需确保服务器已完成 Nginx 安装。对于 Ubuntu 系统，可通过以下命令执行安装：

sudo apt - get update
sudo apt - get install nginx

CentOS 系统则通过 yum 命令安装：

sudo yum install nginx

同时，需安装 OpenSSL 依赖库以提供 SSL/TLS 加密支持，该组件为后续 mTLS 双向认证配置的必要前提。Ubuntu 系统安装命令如下：

sudo apt - get install openssl

CentOS 系统安装命令：

sudo yum install openssl

安装完成后，通过 nginx -V 命令查看 Nginx 编译参数，确认是否包含 --with-stream 模块。该模块是实现 TCP/UDP 四层代理的核心组件，若缺失则需重新编译 Nginx 并添加该参数。

（二）配置步骤详解

  1. 找到并编辑 Nginx 配置文件 ：Nginx 的主配置文件通常位于/etc/nginx/nginx.conf。使用文本编辑器打开该文件，例如使用vim 编辑器：
sudo vim /etc/nginx/nginx.conf
  1. 添加 Stream 配置块 ：在 Nginx 配置文件中，stream 配置块与 http 配置块处于同一层级。在文件中合适的位置添加 stream 配置块，用于定义 TCP 代理规则。例如：
stream {# 这里开始定义 TCP 代理相关配置}
  1. 定义上游服务器组（upstream）：在上游服务器组中，指定后端真实服务器的地址和端口。可以配置多个服务器，实现负载均衡。例如，要代理 MySQL 服务，配置如下：
stream {
    upstream mysql_servers {
        server 192.168.1.100:3306;
        server 192.168.1.101:3306;
    }
}

这里定义了一个名为 mysql_servers 的上游服务器组，包含两个后端 MySQL 服务器。4. 配置代理服务器（server）：在 stream 配置块中，添加 server 配置块，用于监听客户端的连接请求，并将请求代理到上游服务器组。例如：

stream {
    upstream mysql_servers {
        server 192.168.1.100:3306;
        server 192.168.1.101:3306;
    }
    server {
        listen 33060;
        proxy_pass mysql_servers;
        proxy_connect_timeout 10s;
        proxy_timeout 300s;
    }
}
  • listen：指定代理服务器监听的端口，这里监听 33060 端口。
  • proxy_pass：指定要代理到的上游服务器组，这里是mysql_servers。
  • proxy_connect_timeout：设置与后端服务器建立连接的超时时间，这里是 10 秒。
  • proxy_timeout：设置代理会话的超时时间，即如果在 300 秒内没有数据传输，连接将被关闭。

（三）配置示例展示

以下是一个完整的 Nginx 代理 TCP 四层端口的配置示例，代理 Redis 服务：

stream {
    upstream redis_servers {
        server 192.168.1.110:6379;
        server 192.168.1.111:6379;
    }
    server {
        listen 63790;
        proxy_pass redis_servers;
        proxy_connect_timeout 5s;
        proxy_timeout 180s;
        proxy_buffer_size 16k;
    }
}

在这个示例中：

  • 定义了名为 redis_servers 的上游服务器组，包含两个 Redis 服务器。
  • 代理服务器监听 63790 端口，将客户端请求代理到 redis_servers 上游服务器组。
  • 设置了连接超时时间为 5 秒，会话超时时间为 180 秒，并设置了缓冲区大小为 16k，以优化数据传输性能。通过这样的配置，Nginx 就能够高效地代理 TCP 四层端口，实现对后端服务的负载均衡和代理转发功能。

三、启用 mTLS 双向认证加密

（一）mTLS 原理剖析

mTLS，即 Mutual Transport Layer Security（双向传输层安全），是在 TLS 协议基础上的强化，核心在于实现通信双方的双向身份验证。在传统的 TLS 单向认证中，好比访客去访问一座大楼，访客只需确认大楼是他们要去的地方（即客户端验证服务器身份），而大楼门卫不会对访客身份进行严格核查。但在 mTLS 双向认证加密体系下，门卫不仅要确认访客来对了地方，访客也需要确认门卫身份的真实性，只有双方都通过身份验证，才能建立起安全的通信“通道”，让访客顺利进入大楼。

其工作流程基于非对称加密和数字证书技术。在通信开始时，客户端向服务器发送包含自身支持的 TLS 版本、加密套件和随机数等信息的“Client Hello”请求，服务器收到后，回复“Server Hello”，其中包含选定的 TLS 版本、加密套件、自身的数字证书以及“证书请求”，这是 mTLS 与单向 TLS 的关键差异步骤之一，单向 TLS 中服务器不会发送证书请求。

客户端收到服务器的回复后，首先验证服务器证书的有效性，这包括检查证书是否由可信任的证书颁发机构（CA）签发，证书是否在有效期内，证书绑定的域名是否与服务器域名一致，以及证书是否被吊销等。若验证失败，客户端将终止连接；若成功，客户端保存服务器公钥。接着，客户端向服务器发送自己的证书以及用客户端私钥对“客户端随机数 + 服务器随机数 + 会话密钥预主密钥”组合进行签名的“证书验证消息”。

服务器收到客户端证书后，进行类似的有效性验证，并使用客户端公钥解密“证书验证消息”，核对其中的随机数与握手初期的随机数是否一致，以确认客户端确实持有证书对应的私钥，即身份真实。若验证失败，服务器终止连接；若成功，双方进入密钥协商阶段。在这个阶段，客户端与服务器基于各自持有的随机数和预主密钥，通过约定的加密算法生成会话密钥，后续通信数据均通过该会话密钥进行对称加密传输，因为对称加密的效率高于非对称加密，这样既保证了通信的安全性，又兼顾了传输效率。

（二）生成证书与密钥

  1. 生成 CA 证书：CA 证书是整个信任体系的根，它为服务器证书和客户端证书提供信任基础。首先，使用 OpenSSL 生成 CA 私钥，命令如下：
openssl genrsa -aes256 -out ca.key 2048

此命令生成一个 2048 位的 CA 私钥文件ca.key，并使用 AES256 加密算法对私钥进行加密保护。接着，生成 CA 证书请求文件（CSR），命令为：

openssl req -new -sha256 -key ca.key -out ca.csr -subj "/C=CN/ST=Province/L=City/O=Organization/OU=Unit/CN=CA/[email protected]"

在这个命令中，-subj参数用于指定证书的主题信息，包括国家（C）、省份（ST）、城市（L）、组织（O）、组织单位（OU）、通用名称（CN）和邮箱地址（emailAddress）等。生成的 ca.csr 文件包含了 CA 的公钥和身份信息。最后，自签署 CA 证书，命令如下：

openssl x509 -req -days 3650 -sha256 -extensions v3_ca -signkey ca.key -in ca.csr -out ca.crt

该命令使用 CA 私钥对 ca.csr 进行签名，生成 CA 证书 ca.crt，有效期设置为 3650 天，-extensions v3_ca 参数用于指定使用 CA 扩展。2. 生成服务器证书：为服务器生成证书，首先生成服务器私钥：

openssl genrsa -aes256 -out server.key 2048

同样生成一个 2048 位的服务器私钥文件server.key，并进行加密保护。然后生成服务器证书请求文件：

openssl req -new -sha256 -key server.key -out server.csr -subj "/C=CN/ST=Province/L=City/O=Organization/OU=Unit/CN=server.example.com/[email protected]"

这里的 CN 需要填写服务器的域名或 IP 地址。最后，使用 CA 证书签署服务器证书：

openssl x509 -req -days 365 -sha256 -extensions v3_req -CA ca.crt -CAkey ca.key -CAserial ca.srl -CAcreateserial -in server.csr -out server.crt

此命令使用 CA 证书和私钥对服务器证书请求进行签名，生成服务器证书 server.crt，-CAserial 指定 CA 证书的序列号文件，-CAcreateserial表示如果序列号文件不存在则创建它。3. 生成客户端证书：生成客户端证书的步骤与服务器证书类似。首先生成客户端私钥：

openssl genrsa -aes256 -out client.key 2048

接着生成客户端证书请求文件：

openssl req -new -sha256 -key client.key -out client.csr -subj "/C=CN/ST=Province/L=City/O=Organization/OU=Unit/CN=client.example.com/[email protected]"

最后，使用 CA 证书签署客户端证书：

openssl x509 -req -days 365 -sha256 -extensions v3_req -CA ca.crt -CAkey ca.key -CAserial ca.srl -CAcreateserial -in client.csr -out client.crt

这样就生成了客户端证书client.crt。

（三）配置 mTLS

在 Nginx 中配置 mTLS 双向认证加密，需要在之前配置的 TCP 代理基础上进行修改。首先，编辑 Nginx 配置文件 /etc/nginx/nginx.conf，在stream 配置块中的 server 配置块内添加 mTLS 相关配置。

stream {
    upstream mysql_servers {
        server 192.168.1.100:3306;
        server 192.168.1.101:3306;
    }
    server {
        listen 33060 ssl;
        proxy_pass mysql_servers;
        proxy_connect_timeout 10s;
        proxy_timeout 300s;

        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_certificate /path/to/server.crt;
        ssl_certificate_key /path/to/server.key;
        ssl_client_certificate /path/to/ca.crt;
        ssl_verify_client on;
    }
}
  • listen 33060 ssl：表示监听 33060 端口，并启用 SSL 加密。
  • ssl_protocols：指定允许使用的 TLS 协议版本，这里只允许 TLSv1.2 和 TLSv1.3，以保证安全性，避免使用老旧、存在安全风险的协议版本。
  • ssl_ciphers：定义使用的加密套件，选择高强度的加密套件，排除不安全的加密套件，如 aNULL 和MD5，防止被破解。
  • ssl_certificate：指定服务器证书的路径，这里填写实际生成的服务器证书 server.crt 的路径。
  • ssl_certificate_key：指定服务器私钥的路径，即 server.key 的路径。
  • ssl_client_certificate：指定 CA 证书的路径，用于验证客户端证书，这里填写 ca.crt 的路径。
  • ssl_verify_client on：开启对客户端证书的验证，只有客户端提供的证书通过验证，才能建立连接。配置完成后，保存文件并退出编辑器。然后，使用命令 nginx -t 检查配置文件语法是否正确。如果语法无误，重新加载 Nginx 配置，使新配置生效，命令为sudo systemctl reload nginx。通过这样的配置，Nginx 就实现了 TCP 四层端口代理的 mTLS 双向认证加密，保障了通信的安全性。

四、配置验证与测试

（一）检查配置正确性

配置完成 Nginx 代理 TCP 四层端口并启用 mTLS 双向认证加密后，首要任务是检查配置的正确性，这就好比搭建一座桥梁，在通车之前要仔细检查桥梁的结构是否稳固，各个部件是否安装正确。Nginx 提供了便捷的配置检查工具，使用 nginx -t 命令即可检查配置文件的语法是否正确。执行该命令后，如果配置文件没有语法错误，会输出类似“nginx: the configuration file /etc/nginx/nginx.conf syntax is okay”的信息，这就如同桥梁检查人员告诉你桥梁结构没问题，可以进行下一步通车测试；若存在错误，则会详细提示错误所在的行号和具体错误信息，例如“nginx: [emerg] invalid parameter “ssl_protocols” in /etc/nginx/nginx.conf:10”，指出在配置文件的第 10 行，ssl_protocols参数设置有误，此时就需要根据提示信息，仔细检查配置文件，修改错误参数。

此外，还可以查看 Nginx 的错误日志，通常位于 /var/log/nginx/error.log，日志中会记录 Nginx 在启动或运行过程中遇到的各种错误和异常情况，帮助我们进一步排查配置问题。比如，若在日志中发现“SSL_CTX_use_PrivateKey_file (‘server.key’) failed (SSL: error:0909006C:PEM routines:get_name:no start line)”，这表明服务器私钥文件server.key 可能存在格式错误或权限问题，需要检查私钥文件的生成过程是否正确，以及文件权限是否设置为 Nginx 可读取。

（二）测试双向认证加密

在确认配置文件语法无误后，就需要对 mTLS 双向认证加密进行实际测试，以验证其是否真正生效。可以使用 OpenSSL 命令行工具进行测试。例如，使用以下命令模拟客户端连接到启用了 mTLS 双向认证加密的 Nginx 代理服务器：

openssl s_client -connect <server_ip>:<proxy_port> -CAfile /path/to/ca.crt -cert /path/to/client.crt -key /path/to/client.key

其中，<server_ip>是 Nginx 服务器的 IP 地址，<proxy_port>是 Nginx 代理服务器监听的端口，/path/to/ca.crt是 CA 证书的路径，/path/to/client.crt是客户端证书的路径，/path/to/client.key是客户端私钥的路径。

如果 mTLS 双向认证加密配置正确且生效，在执行上述命令后，会看到一系列的握手信息，最终显示“Verify return code: 0 (ok)”，这意味着客户端和服务器的身份验证都成功通过，通信通道建立在安全的加密基础之上，就像双方都通过了严格的安检，顺利进入了安全的通信区域；若认证失败，可能会看到诸如“Verify return code: 21 (unable to verify the first certificate)”的错误信息，此时需要检查证书的配置是否正确，包括证书路径是否准确、证书是否被正确签署、证书是否过期等问题。例如，如果证书路径填写错误，导致无法读取证书，就会出现认证失败的情况；若证书过期，服务器或客户端在验证证书时也会拒绝建立连接。

另外，还可以使用专门的网络测试工具，如 curl 命令，结合证书参数进行测试：

curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key https://<server_ip>:<proxy_port>

通过 curl 命令的返回结果，也能判断 mTLS 双向认证加密是否正常工作。如果能够正常获取到服务器的响应数据，说明配置和认证都成功；若返回错误信息，如“curl: (60) SSL certificate problem: unable to get local issuer certificate”，则需要进一步排查证书相关问题，确保整个 mTLS 双向认证加密体系的安全性和可靠性。

五、总结

使用 Nginx 代理 TCP 四层端口并启用 mTLS 双向认证加密，为网络通信构建了一道坚固的安全防线，同时也提升了网络架构的灵活性和性能。在配置过程中，我们首先需要确保 Nginx 安装并具备 Stream 模块支持，通过精确的配置，实现对 TCP 端口的高效代理，将客户端请求精准地转发到后端服务器组，实现负载均衡，提升服务的可用性和响应速度。

mTLS 双向认证加密的引入，极大地增强了通信双方的身份可信度和数据传输的安全性。从生成 CA 证书、服务器证书和客户端证书，到在 Nginx 中细致地配置证书路径、验证参数等，每一个步骤都至关重要，任何一个环节的疏忽都可能导致安全漏洞或连接失败。通过严格的配置验证和多维度的测试，如使用 nginx -t 检查配置语法，利用 OpenSSL 和 curl 等工具测试双向认证加密效果，确保了整个配置的正确性和安全性。

正文完
Nginx 加密
发表至： 教程资源
近两天内
 0
Fr2ed0m
版权声明：本站原创文章，由 Fr2ed0m 于2025-11-04发表，共计7899字。
转载说明：Unless otherwise specified, all articles are published by cc-4.0 protocol. Please indicate the source of reprint.
Git Hooks实战指南：自动化提升团队代码质量与开发效率
Linux/Unix 信号机制全解：Ctrl+C、Ctrl+Z、kill、pkill、nohup、&、tmux 进程管理详解
HTTP状态码详解：全面理解1xx、2xx、3xx、4xx、5xx分类与示例
Next.js+NextAuth.js接入Google Oauth登录
评论（没有评论）