OpenVPN 路由:多個預設條目。OpenVPN 客戶端:iptables。DNS 問題
在使用公共 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
syslog中的錯誤 ( ) 說明了什麼?它可能與第一個問題有關嗎?編輯:謝謝你的回答,米哈爾。為了減少多播/本地/…流量,我還計劃使用 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 設置為全部接受。
- 路由表看起來不錯,看看指標列。具有最低指標的路線將是首選。您的路由表現在包含兩條預設路由,並且 10.11.12.13 將優先於 192.168.178.1,因為它的指標較低。關於物理介面的流量;這也是正常的,因為您有響應廣播/多播流量的偵聽服務。此流量無法通過 VPN 介面。這也是一些使用本地網路加速的應用程序的標誌,例如:dropbox、teamviewer、upnp、微軟網路鄰居和許多其他功能。
- 很可能’cos /sbin/route 或 /usr/sbin/route 沒有權限做某事,因為您在配置文件中使用指令將 openvpn 的服務權限放棄給使用者nobody,重新連接後它可以對這些事情大喊大叫. 特別是當您更改伺服器的配置並且不以完全權限手動重新啟動客戶端時。這也是正常的。
PS。如果您將遠端與 IP 地址一起使用,則不需要 resolv-retry-infinite,這是沒有意義的。
編輯: iptables configutation 我假設那是 cleint 的 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 嗎?