本文档详细介绍了在Proxmox环境中构建一个透明代理网关的架构。该架构旨在让内网虚拟机（连接至vmbr1）无需客户端配置，即可通过Gateway VM实现DHCP、DNS解析及透明代理上网。文章阐述了Proxmox主机的网络配置（vmbr0, vmbr1）、IP转发与NAT设置，以及Gateway VM的网络配置和Clash Meta（TPROXY模式）的透明代理功能。重点解决了dnsmasq在网关VM上无法启动的问题，分析了潜在的配置错误和端口冲突，并提出了解决DNS路由链断裂的方案，以实现完整的TPROXY功能。

🚀 **透明代理网关架构设计**：该架构的核心目标是在Proxmox上创建一个透明代理网关，为内网虚拟机提供DHCP、DNS服务，并实现透明代理上网。所有内网VM无需额外客户端配置，即可通过Gateway VM访问互联网，链路为Client VM -> Gateway VM (DHCP/DNS) -> Clash Meta (TPROXY) -> Internet。

🌐 **Proxmox与Gateway VM网络配置**：Proxmox主机配置了公网桥vmbr0和内网桥vmbr1，并启用了IP转发和iptables NAT，确保Gateway VM流量能通过Proxmox公网IP出口。Gateway VM被分配静态IP（192.168.1.254/24），仅连接至vmbr1，并作为其他VM的默认网关。

📦 **Clash Meta透明代理实现**：Clash Meta已成功安装并配置为systemd服务，通过TPROXY模式拦截TCP/UDP流量，实现了对出站连接的代理。通过SOCKS5代理（7891端口）的测试确认Clash Meta正常工作，且流量已正确路由至代理IP。

⚠️ **dnsmasq启动失败与DNS解析中断**：当前面临的主要问题是dnsmasq服务在Gateway VM上无法启动，systemd报告配置文件存在错误（exit-code status=2）。这导致VM无法解析DNS，ping google.com失败，直接阻断了透明DNS路由链，是实现完整TPROXY功能的最后一步关键障碍。

💡 **解决DNS路由链的策略**：为解决DNS问题，已禁用systemd-resolved并将resolv.conf指向127.0.0.1，确保DNS流量流经Clash。后续计划让dnsmasq作为LAN的DNS服务器，并将上游DNS查询转发给Clash。解决dnsmasq的启动问题是恢复整个透明代理功能的关键。

背景 / 目标

我在 Proxmox 上做一个 透明代理网关架构，所有内网 VM （接在私有桥 vmbr1 上）不做任何客户端配置，即可通过 Gateway VM 实现：
• DHCP + DNS：dnsmasq 提供地址分配 & 本地 DNS 。
• 透明代理：Clash Meta （ TPROXY 模式拦截 TCP/UDP ）。
• 出网： 通过 Proxmox 宿主机的公网出口做 NAT 。

目标链路：Client VM -> (DHCP/DNS via dnsmasq) -> Gateway VM -> Clash Meta -> Internet 。

我们已成功完成的工作
Proxmox 主机配置：
• 配置了 vmbr0 （公网桥接）和 vmbr1 （内网 LAN ）。
• 启用 IP 转发，并使用 iptables 设置 NAT ，使网关 VM 的流量可以通过 Proxmox 主机的公网 IP 出口。

网关 VM 网络：
• 分配了静态 IP：192.168.1.254/24 。
• 仅连接到 vmbr1 （内网桥）。
• 作为其他 VM 的默认网关。

Clash Meta 设置（透明代理）：
• 安装了 clash-meta 二进制文件并配置了 systemd 服务。
• 验证了通过 SOCKS5 （端口 7891 ）路由的出站连接解析为代理 IP ，确认 Clash Meta 正常工作。
• 使用 iptables 应用了 TPROXY 和 mangle 规则进行流量拦截。

DNS 解析测试：
• 不使用代理时（ curl https://ipinfo.io ）返回 Proxmox 公网 IP 。
• 使用代理时（ curl --socks5 127.0.0.1:7891 https://ipinfo.io ）返回 Clash 代理 IP 。

⸻

当前阻塞问题：dnsmasq 无法启动
为了完成透明路由设置，我们尝试在网关 VM 上配置 dnsmasq 以提供 DHCP 和 DNS 服务。然而目前被以下问题阻碍：
• dnsmasq.service 启动多次失败。
• systemd 报告：exit-code status=2 ，通常意味着配置文件存在语法错误。
The dnsmasq.conf file was configured with the following settings(etc/dnsmasq/.conf):
interface=ens19
dhcp-range=192.168.1.100,192.168.1.200,12h
dhcp-option=3,192.168.1.254
dhcp-option=6,192.168.1.254
no-resolv
server=127.0.0.1
log-queries
log-dhcp
/etc/systemd/system/dnsmasq.service
[Unit]
Description=Custom dnsmasq for DHCP & DNS
After=network.target
[Service]
ExecStart=/usr/sbin/dnsmasq -k --conf-file=/etc/dnsmasq.conf
Restart=on-failure
[Install]
WantedBy=multi-user.tar
服务日志显示，由于第 1 行的问题导致启动失败，尽管语法看起来是正确的。我们正在排查：
• 可能的网卡名称错误（ ens19 ，已确认无误）。
• Clash Meta 占用 53 端口的冲突（已解决）。
• 配置文件中可能存在缩进或不可见字符问题。
目前的分析
• Clash Meta 已经正常运行并通过 TPROXY 成功拦截流量。然而，它并不会为下游 VM 解析 DNS ，除非 DNS 请求被正确转发到 Clash 。
• 已禁用 systemd-resolved ，并将 resolv.conf 指向 127.0.0.1 ，以便让 DNS 流量流经 Clash 。
• 原本计划让 DNSMASQ 作为 LAN 的主要 DNS 服务器，并将上游 DNS 查询转发给 Clash （ 127.0.0.1 ）。但由于 dnsmasq 无法启动，导致 VM 无法解析 DNS ，因此客户端 VM 上 ping google.com 失败。

因此，透明 DNS 路由链断裂，阻碍了完整 TPROXY 功能的最后一步。