公共の Wi-Fi を使用する際のプライバシー保護のため、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 はパブリック Wi-Fi を示します):
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 つのデフォルト エントリがあるため、少し奇妙に見えます。さらに、パブリック Wi-Fi ルーターのトラフィックを記録すると (tcpdump を使用)、すべてのトラフィックが VPN 経由でルーティングされるわけではありません。
ERROR: Linux route add command failed: external program exited with error status: 2syslog のエラー ( ) には何と書かれていますか? 最初の質問と関係があるのでしょうか?
編集: 回答ありがとうございます、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 サーバーへの接続を確立し、その接続上のすべてのトラフィックを処理するのに十分であるはずです。しかし、VPN 接続も使用するはずであるにもかかわらず、DNS は機能しません。なぜ機能しないのでしょうか?
次の編集: 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.1VPN サーバー自体で実行する場合、ホスト名を正常に取得できます。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 all に設定されています。
答え1
- ルーティング テーブルは問題なさそうです。メトリック列を確認してください。最も低いメトリックを持つルートが優先されます。ルーティング テーブルには現在 2 つのデフォルト ルートが含まれており、メトリックが低いため、10.11.12.13 が 192.168.178.1 よりも優先されます。物理インターフェイス上のトラフィックについてですが、ブロードキャスト/マルチキャスト トラフィックに応答するリスニング サービスがあるため、これも正常です。このトラフィックは VPN インターフェイスを経由できません。これは、ローカル ネットワークを使用して処理を高速化する一部のアプリケーションの兆候でもあります。たとえば、Dropbox、TeamViewer、UPnP、Microsoft Network Nearhouse、その他多数の機能があります。
- これはおそらく、/sbin/route または /usr/sbin/route に何かを行う権限がないためです。これは、設定ファイルで、openvpn のサービス権限をユーザー nobody にドロップするディレクティブを使用したためです。再接続後、このようなことが報告される可能性があります。特に、サーバーの設定を変更し、クライアントを完全な権限で手動で再起動しない場合に発生します。これも正常です。
PS. IP アドレスでリモートを使用する場合は、resolv-retry-infinite は必要ありません。意味がありません。
編集: iptables の設定 それはクライアントの iptables 構成だと思います。
- NAT テーブルもフラッシュする必要があります:
iptables -F -t nat
- 次の 2 つの理由により、DHCP 通信にルールは必要ありません。
- DHCP サービスは通常、iptables でカバーされていないいわゆる raw ソケットを使用します (最後に確認したときは、dhcpd、dhcpcd が使用していました)。
- DHCP メカニズムは OpenVPN プロトコルに実装されているため、実際の DHCP 通信 (つまり、DHCP Rrequest、DHCP offer、DHCP ACK、DHCP Pack) は行われません。
- OpenVPN を TCP モードで使用するのはお勧めできません。http://sites.inka.de/bigred/devel/tcp-tcp.html
- 質問を編集して、以下の点をお知らせください。
- クライアント（トンネル通信）からVPNサーバー（VPN IPアドレス）にpingできますか？
- サーバーからnetstat -l -u -n -pを表示します（dnsmasqデーモンがtunインターフェースでリッスンしているかどうかを確認する必要があります）。
- VPN が確立された後、8.8.8.8 に ping できますか?