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 

所以，幾年後，有點聰明。我發現了根本問題。偽裝問題只是部分問題，但我的問題主要是誤診症狀。

所以為了偽裝，我遵循了這個：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 或允許它更改路由。

最後，我的主要問題是我whats my ip在 VPN 退出所在的同一台伺服器上使用我自己的服務。這使得伺服器做了一些內部路由優化，它仍然會告訴我我來自我的“un-vpn:ed”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 用於Internet 共享。

您的 MASQUERADE 規則可能是錯誤的。

您只能偽裝通過 enp2s0 傳出的流量，而不是 tap0。這顯然會導致數據包保留 wlp3s0 的地址作為其源地址，這可以解釋為什麼您的回復會從那裡進入。

引用自：https://serverfault.com/questions/613953