☰

如何将内部网络接口桥接到 OpenVPN tun/tap 设备

tag-icon • tag-icon linux iptables vpn bridge iproute2
如何将内部网络接口桥接到 OpenVPN tun/tap 设备

我正在使用双虚拟机设置，其中第一台虚拟机machine A有一个封闭的私有 LAN，与第二台虚拟机 共享，machine B后者具有第二个网络接口，配置为访问互联网。

内部 LAN 的两个适配器均使用静态 IP 配置；DHCP 已禁用。确认公共 LAN 适配器（中的第二个适配器machine B）已成功接入互联网。

machine A的适配器配置为使用 的 LAN 地址machine B作为其网关地址。

我正在尝试使用 OpenVPN 连接来弥补两个接口之间的差距machine B，以便machine A 透明地通过此 OpenVPN 连接连接到互联网，而无需在机器本身上安装 VPN。

             (private LAN)
  machine A ─────────────────► ens34
                                │
                                ▼
             OpenVPN ────────►tun0 OR
                              tap0
                                │
             (public LAN)       ▼
     WAN ◄─────────────────── ens33

对我来说，OpenVPN 设备是 TUN 还是 TAP 都无所谓。只要能用就行。WAN 卡是否可用machine B或是否完全被配置接管也无所谓 - OpenVPN 连接是通过 VPN 服务，而不是私人/企业网络或类似网络；它旨在让所有流量都通过它作为代理进行路由。

值得一提的是，我的机器上还有第三个接口，ens38由于 SSH 的原因，该接口被配置为仅主机，否则除了调试之外，在所有情况下它都会处于关闭状态。

我打算全部通过 VPN 连接路由的流量（而不仅仅是特定端口）并且宁愿让网络接口的machine A行为尽可能接近将接口配置为直接使用 VPN 连接时的行为。

openvpn --mktun --dev tun0我正在通过/创建 TUN/TAP 设备tap0，然后使用openvpn --config ... --dev tun0/重新使用它们tap0。

我已经确认了以下内容，没有设置额外的路由并且 iptables 为空（由空iptables-save输出确认）：

  • curl ifconfig.me通过 WAN 适配器正确路由，ens33并显示我的真实 IP。
  • curl --interface tun0 ifconfig.me通过 VPN 连接正确路由并显示代理 IP 地址。
  • 流量确实machine B从machine A到达设备ens34，经 确认tcpdump。ARP 正确响应物理地址。
  • sysctl -p返回net.ipv4.ip_forward = 1（我已经ip_forward在系统范围内启用了以下所有尝试）。

第一次尝试是使用数据包标记和 iproute2 路由如本主题所述，但没有任何内容按照 进行tcpdump -i tun0。我的表格是ACCEPT默认的，因此-j LOG显示的调试结果不太理想。

第二次尝试是使用预路由和伪装，使用以下脚本：

#! /bin/bash
set -euo pipefail

IPTABLES=/sbin/iptables

WANIF='tun0'
LANIF='ens34'

# enable ip forwarding in the kernel
echo 'Enabling Kernel IP forwarding...'
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

# flush rules and delete chains
echo 'Flushing rules and deleting existing chains...'
$IPTABLES -F
$IPTABLES -X
$IPTABLES -F -t nat
$IPTABLES -X -t nat

# enable masquerading to allow LAN internet access
echo 'Enabling IP Masquerading and other rules...'
$IPTABLES -t nat -A POSTROUTING -o $LANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $WANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -j ACCEPT

这确实有效当设置WANIF为ens33（公共 WAN 适配器）时machine A-成功地可以通过与外界对话machine B，当然不是通过 VPN。

当使用WANIF=tun0或 时WANIF=tap0，tcpdump这些接口上没有显示任何活动。

第三次尝试是使用DNAT：

iptables -t nat -A PREROUTING --in-interface $LANIF -j DNAT --to-destination 10.8.1.13

10.8.1.13当时TUN设备的IP在哪里。

这没什么作用。

最后一次尝试是使用桥接适配器。我首先尝试使用 TUN 设备，但发现桥接适配器不支持它们，因此我切换到 TAP 设备并运行以下命令：

ip link add br0 type bridge
ip link set tap0 master br0
ip link set dev ens34 down
ip addr flush dev ens34
ip link set dev ens34 up
ip link set ens34 master br0
ip addr add 192.168.4.42 dev br0  # static IP otherwise configured for ens34
ip link set dev br0 up

这成功导致来自的流量machine A到达 TAP 设备，但它将 VPN 网络视为本地对等体，并向 VPN 网络 ARP 请求公共 IP（例如Who has 8.8.4.4? Tell 192.168.4.80）。

我完全不知所措。我想做的事情真的可行吗？为什么 iptables 无法转发到 TUN/TAP 设备？

第二次尝试（伪装）似乎是最好的选择，因为这是我认为的“正确”的解决方案，但 iptables 似乎拒绝路由到 TUN 或 TAP 设备。

答案1

所有类似设置的一般规则是“不要使用 VPN 桥接二层 LAN 段”。它带来的麻烦多于好处。

使用路由/转发。

这是您以后会感激的很好的建议；但是，我完全理解，它现在极有可能吸引负面业力。

相关内容