☰

OpenVPN 路由：多個預設條目。 OpenVPN 用戶端：iptables。 DNS問題

tag-icon • tag-icon domain-name-system iptables routing openvpn dnsmasq
OpenVPN 路由：多個預設條目。 OpenVPN 用戶端：iptables。 DNS問題

我在使用公共 WiFi 時出於隱私目的運行 OpenVPN 伺服器（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 時系統日誌的相關部分：

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.

我的問題是：

  1. 路由表是否正確？對我來說，由於兩個預設條目，它看起來有點奇怪。此外，在公共 WiFi 路由器上記錄流量（使用 tcpdump）時，並非所有流量都會透過 VPN 路由。

  2. ERROR: Linux route add command failed: external program exited with error status: 2系統日誌中的錯誤 ( ) 表示什麼？這可能與第一個問題有關嗎？

編輯：感謝您的回答，米哈爾。為了減少多播/本地/...流量，我還計劃使用 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

IMO，這些規則應該足以獲取網關分配的 IP、建立與 OpenVPN 伺服器的連接並處理該連接上的所有流量。但是，DNS 不起作用，儘管它也應該使用 VPN 連線。為什麼這不起作用？

dnsmasq下一步編輯：在 VPN 伺服器上設定本機名稱伺服器 ( )。伺服器配置更改為

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

  1. 路由表看起來不錯，看看指標列。具有最低度量值的路由將優先選擇。您的路由表現在包含兩個預設路由，並且由於度量值較低，10.11.12.13 將優於 192.168.178.1。關於實體介面上的流量；這也是正常的，因為您有響應廣播/多播流量的監聽服務。此流量無法透過 VPN 介面傳輸。這也是一些使用本地網路來加速的應用程式的標誌，例如：dropbox、teamviewer、upnp、微軟網路鄰居和許多其他功能。
  2. 最有可能的是'cos /sbin/route 或/usr/sbin/route 無權執行某些操作，因為您在設定檔中使用指令將openvpn 的服務權限刪除給使用者無人，重新連線後它可以大喊此類事情。特別是當您更改伺服器的配置並且不以完全權限手動重新啟動客戶端時。這也很正常。

附言。如果您使用具有 IP 位址的遠端伺服器，則不需要 resolv-retry-infinite，這是沒有意義的。

編輯：iptables 配置 我認為這是 cleint 的 iptables 配置。

  1. 您還應該刷新 NAT 表：

iptables -F -t nat

  1. 由於以下兩個原因，您不需要 DHCP 通訊規則：
    • DHCP服務通常使用所謂的原始套接字，這些套接字不被iptables覆蓋（上次我檢查它時，dhcpd、dhcpcd正在使用它），
    • DHCP機制是在OpenVPN協定中實現的，因此沒有任何實際的DHCP通信，我的意思是DHCP Rrequest、DHCP Offer、DHCP ACK、DHCP Pack。
  2. 在 TCP 模式下使用 OpenVPN 是個壞主意：http://sites.inka.de/bigred/devel/tcp-tcp.html
  3. 請編輯您的問題並告訴我是否：
    • 您是否能夠從用戶端（隧道通訊）ping VPN 伺服器（VPN IP 位址）
    • 顯示來自伺服器的 netstat -l -u -n -p （我們需要知道您的 dnsmasq 守護程式是否正在偵聽 tun 介面），
    • VPN建立後能ping通8.8.8.8嗎？

相關內容