在使用公共 wifi 时，为了保护隐私，我运行了一个 OpenVPN-Server（Debian 8）。因此，客户端的所有网络流量都应通过 VPN 连接进行处理。服务器和客户端配置如下。
服务器配置：
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/tlsauth.key 0
user nobody
group nogroup
server 10.11.12.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
persist-key
persist-tun
comp-lzo
status openvpn-status.log
verb 3
客户端配置：
client
remote X.X.X.X 1194
proto tcp
dev tun
resolv-retry-infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
tls-auth /etc/openvpn/tlsauth.key 0
comp-lzo 0
verb 2
当客户端启动VPN服务时，路由表会发生如下改变。
路由表（192.168.178.0/24表示公共wifi）：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.11.12.13 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 1024 0 0 wlan0
10.11.12.1 10.11.12.13 255.255.255.255 UGH 0 0 0 tun0
10.11.12.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.11.12.13 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
X.X.X.X 192.168.178.1 255.255.255.255 UGH 0 0 0 wlan0
启动openvpn时syslog的相关部分：
ovpn-client[3395]: OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 1 2014
ovpn-client[3395]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
ovpn-client[3395]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
ovpn-client[3395]: Control Channel Authentication: using '/etc/openvpn/tlsauth.key' as a OpenVPN static key file
ovpn-client[3395]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3395]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
ovpn-client[3396]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock]
ovpn-client[3396]: TCP connection established with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TCPv4_CLIENT link local: [undef]
ovpn-client[3396]: TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194
ovpn-client[3396]: VERIFY OK: depth=1, [...]
ovpn-client[3396]: VERIFY OK: depth=0, [...]
ovpn-client[3396]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
ovpn-client[3396]: [VPN-Server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TUN/TAP device tun0 opened
ovpn-client[3396]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-client[3396]: /sbin/ip link set dev tun0 up mtu 1500
NetworkManager[556]: <info> (tun0): carrier is OFF
NetworkManager[556]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15)
NetworkManager[556]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14
ovpn-client[3396]: /sbin/ip addr add dev tun0 local 10.11.12.14 peer 10.11.12.13
NetworkManager[556]: <info> (tun0): link connected
ovpn-client[3396]: ERROR: Linux route add command failed: external program exited with error status: 2
ovpn-client[3396]: GID set to nogroup
ovpn-client[3396]: UID set to nobody
ovpn-client[3396]: Initialization Sequence Completed
NetworkManager[556]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[556]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[556]: <info> Activation (tun0) starting connection 'tun0'
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[556]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[556]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[556]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[556]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[556]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[556]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[556]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[556]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[556]: <info> Activation (tun0) successful, device activated.
我的问题是：
路由表是否正确？对我来说，由于有两个默认条目，它看起来有些奇怪。此外，在公共 wifi 路由器上记录流量（使用 tcpdump）时，并非所有流量都通过 VPN 路由。
ERROR: Linux route add command failed: external program exited with error status: 2系统日志中的错误 ( ) 说明了什么？这可能与第一个问题有关吗？
编辑：感谢 Michal 的回答。为了减少多播/本地/... 流量，我还计划使用 iptables 来丢弃这些流量。
我正在尝试使用如下 iptables 规则：
#!/bin/bash
GATEWAY="192.168.178.1"
iptables -F
# Allow loopback device (internal communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow DHCP communication with gateway
iptables -A INPUT -i wlan0 -p udp -s $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp -d $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
# Allow ICMP communication with gateway
iptables -A INPUT -i wlan0 -p icmp -s $GATEWAY/32 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p icmp -d $GATEWAY/32 -j ACCEPT
#Allow VPN establishment
iptables -A OUTPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp --sport 1194 -j ACCEPT
#Accept all TUN connections (tun = VPN tunnel)
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
#Set default policies to drop all communication unless specifically allowed
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
我认为，这些规则足以获取网关分配的 IP、建立与 OpenVPN 服务器的连接并处理该连接上的所有流量。但是，DNS 不起作用，尽管它也应该使用 VPN 连接。为什么不起作用？
下一步编辑：在 VPN 服务器上设置本地名称服务器 ( dnsmasq)。服务器配置更改为
push "dhcp-option DNS 10.11.12.1"
代替
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
在 VPN 服务器本身上运行时dig +short serverfault.com @10.11.12.1，可以成功检索主机名。如果在未使用 VPN 的其他主机上运行该命令 ( dig +short stackoverflow.com @X.X.X.X)，也可以成功检索主机名。但是，当在连接到 VPN 的客户端上运行该命令 ( dig +short stackoverflow.com @10.11.12.1) 时，该命令会失败 ( ;; connection timed out; no servers could be reached)。为什么？Iptables 设置为“接受所有”。
答案1
- 路由表看起来不错，看看度量列。度量最低的路由将被优先选择。您的路由表现在包含两个默认路由，并且由于度量较低，10.11.12.13 将优先于 192.168.178.1。关于物理接口上的流量；这也是正常的，因为您有响应广播/多播流量的监听服务。此流量无法通过 VPN 接口。这也是一些应用程序使用本地网络来加速的标志，例如：dropbox、teamviewer、upnp、微软网络邻居和许多其他功能。
- 这很可能是因为 /sbin/route 或 /usr/sbin/route 没有权限执行某些操作，因为你在配置文件中使用了指令将 openvpn 的服务权限授予用户 nobody，重新连接后它会发出此类警报。尤其是当你更改服务器配置并且没有使用完整权限手动重启客户端时。这也是正常的。
PS. 如果您使用带有 IP 地址的远程服务器，则不需要 resolv-retry-infinite，这没有意义。
编辑：iptables 配置 我认为那是客户的 iptables 配置。
- 您还应该刷新 NAT 表：
iptables -F -t nat
- 由于以下两个原因，您不需要 DHCP 通信规则：
- DHCP 服务通常使用所谓的原始套接字，而 iptables 并未涵盖这些套接字（上次我检查时，dhcpd、dhcpcd 正在使用它），
- DHCP 机制是在 OpenVPN 协议中实现的，因此没有任何实际的 DHCP 通信，我的意思是 DHCP Rrequest、DHCP offer、DHCP ACK、DHCP Pack。
- 在 TCP 模式下使用 OpenVPN 不是一个好主意：http://sites.inka.de/bigred/devel/tcp-tcp.html
- 请编辑您的问题并告诉我：
- 您可以从客户端 (隧道通信) ping VPN 服务器 (VPN IP 地址) 吗
- 从服务器显示 netstat -l -u -n -p （我们需要知道你的 dnsmasq 守护进程是否正在监听 tun 接口），
- VPN 建立后，您能 ping 8.8.8.8 吗？