nginx的tcp透明代理设置

Posted 2023-04-23

参考技术A 目前，接入层access使用nginx作为反向代理。客户端连接nginx打开的5000端口后，nginx通过客户端ip哈希的方式，将客户端的接入请求负载均衡到后台的4个access服务。
使用nginx作为反向代理时，客户端与nginx直连，同时nginx为每一个客户端连接建立了单独的tcp连接到access服务。此时，nginx代理带来的问题是，access无法获取到客户端的真实ip，而只能拿到nginx代理服务所在机器的ip。（所有的代理都有类似的问题，因为与上游服务（例如这里的access服务）连接的实际上是代理服务器，ip包里的ip地址是代理服务器的地址）。
但是，很时候我们需要拿到客户端的真实ip做一些业务上的判断。这个时候，就需要通过某些方式获取客户端的真实ip。如果代理服务器和上游服务之前是通过http通讯，则可以通过http的首部 X-Forwarded-For 将客户端的ip信息传给上游服务(nginx可以很方便的设置该首部设置)。
对于纯tcp代理，则获取客户端ip会麻烦一些。主要有两种方式：

nginx作为上游服务的反向代理时，每个客户端的连接方式如下:

实现透明代理的原理是，nginx使用获取到的客户端ip来建立nginx与上游服务直接的tcp连接。也即:

总共有两台服务器，内网ip地址分别为 172.19.228.32 和 172.19.228.33 。两台机器部署的服务如下：

nginx设置完成并reload配置后，所有从nginx发送到上游服务器的ip数据包将使用客户端的ip地址作为源地址。后续的设置，需要将上游服务器返回的ip数据包（其中的目的地址是客户端的ip）返回到nginx所在的机器，并投递给nginx进程。

32机器上的上游服务返回ip数据包给nginx时，指定的目的ip地址是客户端的ip地址。32机器需要将这些数据返回给nginx进程。

设置完成后，32上的上游服务(端口为15010以及15011)发出的ip数据包，因为被设置了标记而匹配新增的策略路由，所有ip数据被路由到lo网络接口。同时，因为这些数据包中包含的端口是nginx连接上游服务时打开的端口，所以这些数据最终被分用到nginx进程。
这样，nginx和同在一个机器上的上游服务之间的透明代理设置完整。上游服务将可以得到客户端的ip地址，同时可以将数据返回给nginx，nginx再将返回的数据返回给对应的客户端。
此时，如果使用 lsof(1) 命令查看上游服务打开的tcp链接，显示的源ip地址也将是客户端的ip地址。

33上的上游服务与nginx在不同的主机上。主要设置如下：

设置完成后，33可以接收nginx发出的ip数据包，并可以将上游服务回复的ip数据路由给32机上的nginx进程。
同时，使用 lsof(1) 命令查看33的上游服务打开的tcp链接，源ip将是客户端的ip。其他所有的与nginx不在同一个主机上的上游服务都可以参考这个配置设置。

参考：
nginx的透明代理实现
IP Transparency and Direct Server Return with NGINX and NGINX Plus as Transparent Proxy
Linux kernel rp_filter settings

TCP 代理到 postgres 数据库作为 nginx 中的上游服务器

【中文标题】TCP 代理到 postgres 数据库作为 nginx 中的上游服务器

【英文标题】：TCP proxy to postgres database as an upstream server in nginx

【发布时间】：2016-06-03 09:46:53

【问题描述】：

问题：是否可以将 Nginx 设置为数据库的反向代理？ 这些是我目前拥有的标志，我相信拥有 --with-stream 模块足以使用 TCP 流到数据库。这是 PLUS 功能吗？

Nginx 配置选项：

--prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=%_libdir/nginx/modules --conf-path=/etc/nginx/nginx. conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx。 pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/ nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/ var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with -http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with -http_slice_module --with-邮件 --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE =2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6

Nginx 配置

stream 

    include conf.d/streams/*.conf;

conf.d/streams/upstream.conf的内容

upstream database_server 
    least_conn;
    keepalive 512;
    server 192.168.99.103:32778 max_fails=5 fail_timeout=30s weight=1;

来自 Nginx 的错误消息

2016/02/22 03:54:13 [emerg] 242#242：/etc/nginx/conf.d/streams/database_server.conf:9 中上游“http://database_server”中的主机无效

【参考方案1】：

问题是“http://database_server” 它是一个 tcp 流，所以你只需要 proxy_pass database_server

也保持活动不是进入 tcp 上游服务器的指令

【参考方案2】：

这是一个对我有用的 nginx 配置（我正在运行 inside Docker，所以其中一些选项可以帮助解决这个问题）：

worker_processes auto;

daemon off;

error_log stderr info;

events 
    worker_connections 1024;


stream 
    upstream postgres 
        server my_postgres:5432;
    

    server 
        listen 5432 so_keepalive=on;
        proxy_pass postgres;
    

对我来说，关键是listen 5432 so_keepalive=on; 行，它开启了 TCP keepalive。没有它，我可以连接，但我的连接会在几秒钟后重置。

【讨论】：

我想my_postgres:5432 代表名称为my_postgres 的docker 容器，对吗？我也在为我的 docker 东西尝试这个。

这里，my_postgres 是解析为侦听端口 5432 的服务器的名称。如果您有 docker-compose 配置，您可以将 Postgres 容器命名为 my_postgres，然后 Docker 会设置为您解析名称。但你可能不在 Docker 之外，只使用 DNS。

对我来说，尝试使用此配置从客户端连接到 postgres 时连接超时。

@BielSimon 如果您在连接时超时，那么您的 Nginx 将无法访问您的 Postgres。可能其中一个或两个都配置错误（可能 Postgres 没有在正确的接口上侦听，可能 Nginx 使用了错误的端口等）。