☰

VPN 路由流量，响应超出 VPN 范围吗？

tag-icon • tag-icon iptables vpn routing openvpn nat
VPN 路由流量，响应超出 VPN 范围吗？

这是一个很奇怪的现象。

每当我使用酒店网络时，我都倾向于将所有流量路由到家庭网络。主要是因为我不完全确定我的所有密码是否始终通过 SSL。

因此我得到了以下 OpenVPN 服务器设置：

persist-key 
dev tap
keepalive 10 120
port 1194
verb 3
status openvpn-status.log
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 8.8.8.8"
persist-tun 
dh dh2048.pem
cert vpnserver.crt
key vpnserver.key
tls-auth ta.key 0
ca ca.crt
proto udp
comp-lzo 
cipher AES-128-CBC
ifconfig-pool-persist ipp.txt
client-to-client

它与这些 iptable 规则配合得很好：（它正在测试中，所以这里有一些东西还没有真正清理干净..但截至目前，我无法触及其中任何一个来确定哪些应该保留，哪些应该删除，因为我现在正在旅行..）

*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
# ==
# == ROUTING
# ==
-A POSTROUTING -o enp2s0 -j MASQUERADE
# ==
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:TCP - [0:0]
:UDP - [0:0]
:fw-interfaces - [0:0]
:fw-open - [0:0]
# ==
# == BRIDGE ROUTING
# ==
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw-interfaces
-A FORWARD -j fw-open
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
# ==
# == Accepts
# ==
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A TCP -p tcp -m tcp --dport 443 -j ACCEPT
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A UDP -p udp -m udp --dport 53 -j ACCEPT
# ==
# == Forwards
# ==
-A fw-interfaces -i tap0 -j ACCEPT
# == VPN route
-A FORWARD -i enp2s0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tap0 -o enp2s0 -j ACCEPT
# == VPN
-A INPUT -p udp -m state --state NEW,RELATED,ESTABLISHED -m udp --dport 1194 -j ACCEPT
-A OUTPUT -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 1194 -j ACCEPT
# == DNS
-A INPUT -i enp2s0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --dport 53 -j ACCEPT
# == WEB-outgoing
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 443 -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 80 -j ACCEPT
# == WEB-incomming
-A INPUT -p tcp -m tcp -m state --state NEW,RELATED,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp -m state --state ESTABLISHED,RELATED --sport 80 -j ACCEPT
# ==
# == TAP0
# ==
-A INPUT -i tap0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o tap0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i tap0 -p udp --dport 67 -j ACCEPT
#-t nat -A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
-A FORWARD -i tap0 -s 10.8.0.0/24 -o enp2s0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# ==
# == GENERIC
# ==
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A FORWARD -i tap0 -j ACCEPT
# ==
# == REJECTS
# ==
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
*nat
-A POSTROUTING -s 192.168.1.0/24 -o enp2s0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
COMMIT

# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*mangle
:PREROUTING ACCEPT [76747:82460059]
:INPUT ACCEPT [18221:1445339]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17305:8505640]
:POSTROUTING ACCEPT [75742:89503746]
COMMIT
# Completed on Thu Jun  5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -o enp2s0 -j MASQUERADE
COMMIT
# Completed on Thu Jun  5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*filter
:INPUT ACCEPT [18037:1435358]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17119:8490056]
-A FORWARD -i enp2s0 -o wlp3s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlp3s0 -o enp2s0 -j ACCEPT
COMMIT
# Completed on Thu Jun  5 18:54:09 2014

不过，这只是一种可行的方法，因为流量肯定会通过 VPN 路由。
但响应流量会出于某种原因返回到 VPN 网络之外，而这并不是我们所希望的。我假设这些MASQUERADE线路都是错的？

以下是一个例子：
在此处输入图片描述

但当我执行跟踪时，响应会返回到 VPN 之外：
在此处输入图片描述

我的路由没问题，DNS 也正常工作，所以我再次假设我MASQUERADE在 iptables 中出了问题？也许我试图桥接来自两个接口的流量，把事情搞得太复杂了enp2s0（我删掉了一些br0，只是192.168.1.0/24为了缩短规则）

编辑：这是我的路线（wlp3s0=wifi）：

[torxed@archie ~]$ ip route
0.0.0.0/1 via 10.8.0.1 dev tap0 
default via 192.168.1.254 dev wlp3s0 
10.8.0.0/24 dev tap0  proto kernel  scope link  src 10.8.0.2 
109.X.X.X via 192.168.1.254 dev wlp3s0 
128.0.0.0/1 via 10.8.0.1 dev tap0 
192.168.1.0/24 dev wlp3s0  proto kernel  scope link  src 192.168.1.81

答案1

你的 MASQUERADE 规则可能有误。

您只伪装通过 enp2s0 发出的流量，而不是 tap0。这显然会导致数据包保留 wlp3s0 的地址作为其源地址，这可以解释为什么您的回复会通过那里进入。

答案2

几年后，我变得更聪明了。我发现了问题的根源。伪装问题只是部分原因，但我的问题主要是误诊了症状。

为了伪装我遵循了以下操作：https://unix.stackexchange.com/questions/283801/iptables-forward-traffic-to-vpn-tunnel-if-open

ip.net.ipv4.forwarding=1这样您就可以在内核中完成大部分操作。
然后push "redirect-gateway def1 bypass-dhcp"确保路由实际上“覆盖”了默认网关。并确保以提升的权限运行 openvpn-client 或允许它更改路由。

最后，我的主要问题是我在 VPN 出口所在的同一台服务器上使用自己的whats my ip服务。这使得服务器进行一些内部路由优化，但它仍然会告诉我我来自“未使用 VPN”的 IP。这真是太令人困惑了。这就是让我头疼了很长时间的事情。

为了简化冗长的 iptables，我最终使用了以下内容：

iptables -t nat -A POSTROUTING -o internet0 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i net0 -o internet0 -j ACCEPT

摘自 Arch Linux wiki网络共享。

相关内容