OpenVPNルーティング：複数のデフォルトエントリ。 OpenVPNクライアント：iptables。 DNSの問題

Question

パブリック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.

私の質問は次のとおりです。

ルーティングテーブルは正しいですか？私にとっては、2つのデフォルトエントリがあるため、少し奇妙に見えます。さらに、（tcpdumpを使用して）パブリックwifiルーターでトラフィックを記録する場合、すべてのトラフィックが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接続を使用することも想定されていますが、機能しません。なぜそれが機能しないのですか？

次の編集：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"

実行時Dig +short serverfault.com @10.11.12.1 VPNサーバー自体で、ホスト名を正常に取得できました。コマンドが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はすべてACCEPTに設定されています。

Michal Sokolowski · Accepted Answer

ルーティングテーブルは問題ないようです。メトリック列を見てください。メトリックが最も低いルートが優先されます。ルーティングテーブルには2つのデフォルトルートが含まれ、メトリックが低いため、10.11.12.13が192.168.178.1よりも優先されます。物理インターフェイスのトラフィックについて。ブロードキャスト/マルチキャストトラフィックに応答するリスニングサービスがあるため、これも正常です。このトラフィックはVPNインターフェースを経由できません。これは、ローカルネットワークを使用して処理を高速化する一部のアプリケーションの兆候でもあります。たとえば、dropbox、teamviewer、upnp、Microsoftネットワークネイバーフッド、その他多くの機能です。
おそらく 'cos/sbin/routeまたは/ usr/sbin/routeには何かをする権限がありません。これは、設定ファイルでディレクティブを使用してopenvpnのサービス権限をユーザーにドロップしたためです。再接続後、そのようなことについて怒鳴ることがあります。。特に、サーバーの構成を変更し、完全な権限でクライアントを手動で再起動しない場合。それも正常です。

PS。 IPアドレスを使用してリモートを使用する場合は、resolv-retry-infiniteは必要ありません。意味がありません。

EDIT：iptables configutationそれがcleintのiptables構成だと思います。

NATテーブルもフラッシュする必要があります：

iptables -F -t nat