opvnvpn：LANビハインドのノードのアドレス指定

Question

リモートでアクセスできるopenvpnサーバーをセットアップしました。接続すると、サーバーとクライアントの両方に仮想IP10.15.119.xでtun0デバイスが作成されます。 openvpnサーバー自体は10.15.119.1です。

質問： openvpnサーバーの背後にあるLAN内の他のノードをアドレス指定するにはどうすればよいですか？アドレス10.15.119.1 :(ポート）でopenvpnサーバー自体のサービスにアクセスできますが、openvpnサーバーと同じLANにあるopenvpn接続に参加していない他のノードにアドレス指定する方法がわかりません：- このようなノードがクライアントノードから10.15.119.x範囲の他の仮想IPでアドレス指定できることを願っています。その場合は、それらのIPが何であるかを知る方法だけが必要です ==

ポートを他の特定のノードに転送するためにいくつかのiptablesとrouteコマンドを作成することは非常にうまくできますが、ノードを直接アドレス指定する、より良い方法が必要だと確信しています

server.conf：

dev tun server 10.15.119.0 255.255.255.0 ifconfig-pool-persist ipp.txt Push "route 192.168.0.0 255.255.255.0" up ./office.up tls-server dh /home/lurscher/keys/dh1024.pem ca /home/lurscher/keys/ca.crt cert /home/lurscher/keys/vpnCh8TestServer.crt key /home/lurscher/keys/vpnCh8TestServer.key status openvpn-status.log log openvpn.log comp-lzo verb 3

office.upスクリプトには次のものがあります。

#!/bin/sh #route 10.15.119.0 255.255.255.0 route add -net 10.15.119.0 netmask 255.255.255.0 gw $5 #fixed the wrong 10.15.0.0 address

client.confには、代わりに次のものがあります。

dev tun remote my.server.com tls-client pull ca /home/chuckq/keys/ca.crt cert /home/chuckq/keys/vpnCh8TestClient.crt key /home/chuckq/keys/vpnCh8TestClient.key ns-cert-type server ; port 1194 ; user nobody ; group nogroup status openvpn-status.log log openvpn.log comp-lzo verb 3

新規サーバーからの関連ログ：

Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 Push: Received control message: 'Push_REQUEST' Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 SENT CONTROL [vpnCh8TestClient]: 'Push_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' (status=1) Thu May 26 17:02:17 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 Replay-window backtrack occurred [1]

クライアントからの関連ログ：

Thu May 26 16:53:30 2011 [vpnCh8TestServer] Peer Connection Initiated with [AF_INET]X.X.X.X:1194 Thu May 26 16:53:32 2011 SENT CONTROL [vpnCh8TestServer]: 'Push_REQUEST' (status=1) Thu May 26 16:53:32 2011 Push: Received control message: 'Push_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' Thu May 26 16:53:32 2011 OPTIONS IMPORT: --ifconfig/up options modified Thu May 26 16:53:32 2011 OPTIONS IMPORT: route options modified Thu May 26 16:53:32 2011 ROUTE default_gateway=10.21.2.254 Thu May 26 16:53:32 2011 TUN/TAP device tun0 opened Thu May 26 16:53:32 2011 TUN/TAP TX queue length set to 100 Thu May 26 16:53:32 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500 Thu May 26 16:53:32 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5 Thu May 26 16:53:32 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5 Thu May 26 16:53:32 2011 Initialization Sequence Completed

[〜＃〜] edit [〜＃〜] office.upのタイプミスに気付いたwolfgangszのおかげで、改善せずにtracepathを再試行しました。

$ tracepath 192.168.0.100 1: 10.15.119.6 0.261ms pmtu 1500 1: 10.15.119.1 88.989ms 1: 10.15.119.1 58.752ms 2: no reply

iPがopenvpnサーバーからのものである場合の結果の違いに注意してください

$ tracepath 192.168.0.101 1: 10.15.119.6 0.308ms pmtu 1500 1: 192.168.0.101 115.713ms reached 1: 192.168.0.101 65.064ms reached Resume: pmtu 1500 Hops 1 back 64

クライアントでのルーティングエントリ：

$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.15.119.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.1 10.15.119.5 255.255.255.255 UGH 0 0 0 tun0 192.168.0.0 10.15.119.5 255.255.255.0 UG 0 0 0 tun0 10.21.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 10.21.2.254 0.0.0.0 UG 0 0 0 eth0

（openvpn）サーバーでのルーティングエントリ：

$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.15.119.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.0 10.15.119.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vboxnet0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 0.0.0.0 0.0.0.0 U 1002 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 1004 0 0 vboxnet0

編集2： IP転送が有効になっていることを確認しました

$ cat /proc/sys/net/ipv4/ip_forward 1

サーバー内のiptablesの出力は次のとおりです。

$ Sudo iptables -nv -L Chain INPUT (policy DROP 1 packets, 52 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- eth0 * 0.0.0.0/0 127.0.0.1 0 0 DROP all -- eth0 * 192.168.0.0/16 0.0.0.0/0 0 0 DROP all -- eth0 * 172.16.0.0/12 0.0.0.0/0 0 0 DROP all -- eth0 * 10.0.0.0/8 0.0.0.0/0 8 416 ACCEPT all -- * * 127.0.0.1 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 127.0.0.1 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 91 8915 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 293 28499 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 1 1500 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0 18 2010 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- eth0 * 0.0.0.0/0 127.0.0.1 0 0 DROP all -- eth0 * 192.168.0.0/16 0.0.0.0/0 0 0 DROP all -- eth0 * 172.16.0.0/12 0.0.0.0/0 0 0 DROP all -- eth0 * 10.0.0.0/8 0.0.0.0/0 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spts:137:139 0 0 DROP udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spts:137:139 0 0 DROP all -- eth1 * !10.0.0.0/24 0.0.0.0/0 38 57000 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT 306 packets, 34543 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spts:137:139 0 0 DROP udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spts:137:139 0 0 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW

編集

重要な情報を省いてしまったと思います。関連性があるとは思いませんでしたが、最近の回答で、そうかもしれないと思いました。 openvpnはルーターに直接接続されており、ルーター構成（192.168.0.1）でopenvpnポート1194のopenvpnサーバーへのポート転送を有効にしました。これが現在リモートで接続している方法です。

編集4

10.15.119.xルートへのルートを指定してこれを解決できるかどうかを確認するために、192.168.0.100（セカンダリサーバー）マシンで次のコマンドを実行しようとしました。

Sudo route add -net 10.15.119.0 netmask 255.255.255.0 gw 192.168.0.101

（192.168.0.101はopenvpnサーバーアドレス、192.168.0.100は外部から到達したいセカンダリサーバーです）

私はこれを試しましたが、ping 10.15.119.1はopenvpnサーバーにアクセスするために機能しますが、ping 10.15.119.6（私のクライアントIP）は失敗します

編集5

クライアントから192.168.0.100にpingを実行しようとしたときに、openvpnサーバーにtcpdumpの結果を追加しました。

$ Sudo tcpdump -v -i any Host 192.168.0.100 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 11:10:43.675915 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 1, length 64 11:10:43.675932 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 1, length 64 11:10:43.676149 IP (tos 0x0, ttl 64, id 40127, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 1, length 64 11:10:43.778583 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103) services-Host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-Host-1.local. (75) 11:10:43.778588 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103) services-Host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-Host-1.local. (75) 11:10:44.681801 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 2, length 64 11:10:44.681809 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 2, length 64 11:10:44.682007 IP (tos 0x0, ttl 64, id 40128, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 2, length 64 11:10:45.689926 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 3, length 64 11:10:45.689933 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 3, length 64 11:10:45.690121 IP (tos 0x0, ttl 64, id 40129, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 3, length 64 11:10:46.698990 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 4, length 64 11:10:46.698997 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 4, length 64 11:10:46.699190 IP (tos 0x0, ttl 64, id 40130, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 4, length 64 11:10:47.706870 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 5, length 64 11:10:47.706878 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 5, length 64 11:10:47.707067 IP (tos 0x0, ttl 64, id 40131, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 5, length 64 11:10:48.680540 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has services-Host-1.local tell openvpnServer, length 28 11:10:48.680737 ARP, Ethernet (len 6), IPv4 (len 4), Reply services-Host-1.local is-at 08:00:27:a4:e2:01 (oui Unknown), length 28 11:10:48.684812 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dfdlinkrouter tell services-Host-1.local, length 28 11:10:48.685338 ARP, Ethernet (len 6), IPv4 (len 4), Reply dfdlinkrouter is-at 00:26:5a:ae:90:88 (oui Unknown), length 46 11:10:48.716100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 6, length 64 11:10:48.716107 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-Host-1.local: ICMP echo request, id 2494, seq 6, length 64 11:10:48.716347 IP (tos 0x0, ttl 64, id 40132, offset 0, flags [none], proto ICMP (1), length 84) services-Host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 6, length 64

pingがサーバーに到達しているようで、彼は返信しますが、パケットはVPNに入る前にドロップされるので、iptablesに行を追加して、ドロップまたは拒否されたすべてのINPUTパケットとFORWARDパケットをログに記録します。 /var/log/syslog

May 30 10:59:24 openvpnServer kernel: [40433.898392] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=98 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=78 May 30 10:59:24 openvpnServer kernel: [40434.001003] iptables INPUT denied: IN=eth1 OUT= MAC=01:00:5e:00:00:fb:08:00:27:a4:e2:01:08:00 SRC=192.168.0.100 DST=224.0.0.251 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=42 May 30 10:59:24 openvpnServer kernel: [40434.001102] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=72 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=52 May 30 11:03:28 openvpnServer kernel: [40677.329586] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47 May 30 11:03:29 openvpnServer kernel: [40678.330065] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47

iptablesからほとんどのDROPコマンドとREJECTコマンドをコメントアウトして、それが機能するかどうかを確認しましたが、それでも同じ問題が発生します。すべてのドロップを削除した後のiptablesを次に示します。

$ Sudo iptables -L -nv Chain INPUT (policy ACCEPT 88 packets, 15209 bytes) pkts bytes target prot opt in out source destination 3404 3162K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- !lo * 0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable 2950 249K ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 12881 6906K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 162 9696 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 60 10407 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables INPUT denied: ' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 30 2448 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables FORWARD denied: ' Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2826 857K ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0 17443 5842K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

編集6

stevenが提案したように、クライアントから実行中に、サーバーに2つ、クライアントに1つ、合計3つのtcpdumpを追加しました。

$ ping 192.168.0.100 PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data. ^C --- 192.168.0.100 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4024ms

しかし、最初に私はopenvpnサーバーでal iptablesルールをフラッシュしました：

$ Sudo iptables -L -nv Chain INPUT (policy ACCEPT 206 packets, 26537 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 50 packets, 7781 bytes) pkts bytes target prot opt in out source destination

これがopenvpnサーバーでの最初のtcpdumpの出力です

$ Sudo tcpdump -vn -i tun0 '(Host 192.168.0.100 or Host 10.15.119.6)' and icmp tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 13:54:30.871403 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64 13:54:31.870534 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64 13:54:32.879562 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 3, length 64

サーバー上の2番目のtcpdump：

$ Sudo tcpdump -vn -i eth1 '(Host 192.168.0.100 or Host 10.15.119.6)' and icmp tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 13:54:30.871429 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64 13:54:30.875508 IP (tos 0x0, ttl 64, id 28969, offset 0, flags [none], proto ICMP (1), length 84) 192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 1, length 64 13:54:31.870544 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64 13:54:31.870760 IP (tos 0x0, ttl 64, id 28970, offset 0, flags [none], proto ICMP (1), length 84) 192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 2, length 64

そして3番目のtcpdump、今回はクライアント上：

$ Sudo tcpdump -vn -i eth0 Host 192.168.0.100 and icmp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel

[〜＃〜] important [〜＃〜]これは、私が実行したクライアントでip route showを実行したときに役立つ可能性のある他の何かです。

$ Sudo ip route show 10.15.119.5 dev tun0 proto kernel scope link src 10.15.119.6 10.15.119.1 via 10.15.119.5 dev tun0 192.168.0.0/24 via 10.15.119.5 dev tun0 10.21.2.0/24 dev eth0 proto kernel scope link src 10.21.2.118 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 10.21.2.254 dev eth0 proto static

openvpnサーバーで同じコマンド

$ Sudo ip route show 10.15.119.2 dev tun0 proto kernel scope link src 10.15.119.1 10.15.119.0/24 via 10.15.119.2 dev tun0 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.101 metric 1 169.254.0.0/16 dev eth1 scope link metric 1000 default via 192.168.0.1 dev eth1 proto static

openvpnバージョン：

$ openvpn --version OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] 2010年7月12日に構築元々はJamesYonanによって開発されましたCopyright（C ）2002-2009 OpenVPN Technologies、Inc。

オペレーティングシステムはUbuntu10.10x86_64です

なぜクライアントログを取得するのですか？

ue May 31 14:45:41 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500 Tue May 31 14:45:41 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5 Tue May 31 14:45:41 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5

仮想ネットワークの255.255.255.255マスクについてはどうですか？

@skrewler、これはnetstatの結果です：

まず、openvpnの実行中にクライアントから：

$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.15.119.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.1 10.15.119.5 255.255.255.255 UGH 0 0 0 tun0 192.168.0.0 10.15.119.5 255.255.255.0 UG 0 0 0 tun0 10.21.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.21.2.254 0.0.0.0 UG 0 0 0 eth0 $ ifconfig -a eth0 Link encap:Ethernet HWaddr 08:00:27:0c:86:1c inet addr:10.21.2.118 Bcast:10.21.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe0c:861c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22701 errors:0 dropped:0 overruns:0 frame:0 TX packets:12806 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2855655 (2.8 MB) TX bytes:1224261 (1.2 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480 (480.0 B) TX bytes:480 (480.0 B) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.15.119.6 P-t-P:10.15.119.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

およびclient.conf：

dev tun0 remote my.server.com tls-client pull ca keys/ca.crt cert keys/client.crt key keys/client.key ns-cert-type server status logs/openvpn-status.log log logs/openvpn.log comp-lzo verb 4

第二に、openvpnサーバーから

$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.15.119.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.0 10.15.119.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

server.conf

dev tun server 10.15.119.0 255.255.255.0 ifconfig-pool-persist ipp.txt Push "route 192.168.0.0 255.255.255.0" tls-server dh keys/dh1024.pem ca keys/ca.crt cert keys/openvpn-server-key.crt key keys/openvpn-server-key.key user nobody group nogroup status openvpn-status.log log logs/openvpn.log comp-lzo verb 4

上記の設定で私はできる：

1）クライアントから192.168.0.101（openvpnサーバー）へのping 2）openvpnserverから10.15.119.6（クライアント）へのping

私ができないことは、クライアントから192.168.0.100（セカンダリLANサーバー）にpingを実行することです。

192.168.0.100は、openserverのtcpdumpが示すように、実際にはクライアントに応答しますが、どういうわけか、これらのパケットはクライアントに返されません。

skrewler · Accepted Answer

私は応答を調べました、そして私はあなたがこれらすべてでどこにいるかに精通していると思います。

問題を絞り込むためにいくつかの簡単なチェックを行いましょう：

192.168.0.xホストにpingできないOpenVPNクライアントの1つから：netstatn -rn * nixの場合はifconfig -a、またはipconfig /all ping <openvpn server external 10.21.x address> ping <openvpn 10.15.x address

Openvpnサーバーから：netstatn -rn ping <a 192.168.0.x Host> ping <a 10.15.x Host> ping <a 10.21.x Host>

また、現在のopenvpnサーバー構成とクライアント構成はおそらく/etc/openvpn/server.confにあり、クライアントマシンでは/etc/openvpn/<hostname>.confまたはc:\program files\openvpn\config\<hostname.conf> or .ovpnにあります。

私も同様の設定をしています。私のOpenVPNサーバーには、このiptablesルールと同等のものがあります（ホストマスク/インターフェイスを値に変更）：

# Generated by iptables-save v1.4.4 *nat :PREROUTING ACCEPT [5:332] :POSTROUTING ACCEPT [5:740] :OUTPUT ACCEPT [5:740] -A POSTROUTING -s 10.15.119.0/2 -o eth1 -j MASQUERADE COMMIT

Iptable_natがないため、問題は間違いなく発生しているようです。

# lsmod | grep nat iptable_nat 5011 1 nf_nat 19101 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 12548 3 iptable_nat,nf_nat nf_conntrack 72270 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 ip_tables 17942 2 iptable_nat,iptable_filter x_tables 21613 3 ipt_MASQUERADE,iptable_nat,ip_tables

modprobe iptable_natまたは、-aパラメーターを試してください。

dmourati · Answer

これを試して：

サーバーにiptablesSNATルールを追加します。

iptables -t nat -A POSTROUTING -s 10.15.119.0/24 -o eth0 -j SNAT --to-source 10.21.2.118

これにより、そのネットワーク内の他のサーバーへのVPNクライアントIP接続が機能/ルーティングされたNATに戻ります。

wolfgangsz · Answer

ルートをクライアントにプッシュする必要があります。これは、サーバー構成ファイルの「プッシュ」オプションを使用して行われます。

デフォルトでは、OpenVPNサーバーは自分自身にルートをプッシュするだけです。

一般に、VPNサーバーをセットアップするときは、VPNを別のサブネットで機能させることをお勧めします。これにより、ルーティングが容易になり、ファイアウォールのセットアップも容易になります。例：

OpenVPNサーバーを実行しているサーバーの内部IPアドレスは10.15.119.1です。そのパブリックIPアドレスは123.1.2.3です。また、内部ネットワーク全体は10.15.119.0/24にあります。次に、OpenVPNサーバーを10.15.120.0/24で実行するように設定します。これにより、最大63のクライアント接続が可能になります（各接続には4つのIPアドレスの小さなサブネットが必要です）。接続する最初のクライアントは、IPアドレス10.15.120.5を取得します。ここでルートを10.15.119.0/24にプッシュすると、クライアントはルーティングテーブルにルートを追加して、このサブネットのすべてのトラフィックがトンネルに入るようにします。次に、OpenVPNサーバーは、このトラフィックをプライベートイーサネット接続に転送します。

ルートをプッシュする方法の正確な詳細については、OpenVPNのマニュアルページ（またはインターネット上のドキュメント）をお読みください。

Magellan · Answer

おそらく私は正しく理解していませんが、VPNサーバーの背後に到達しようとしている機器には、OpenVPNクライアントサブネットを指すように構成されたルートがありますか？

デフォルトゲートウェイではなく、別のルートが必要なシステムでOpenVPNを実行している場合、それらのサーバーはパケットをクライアントに戻すことができません。

OpenVPNサーバーから発信されたpingは、機器がルーティングできるインターフェイスから送信されますが、他のサーバーがそのルートを知らない場合、クライアントに戻るpingには戻るルートがない可能性があります。

サーバーでクライアントトラフィックをNAT変換している場合、これは関係ないかもしれませんが、投稿した構成でそれを示すものは何も見ていません。

Steven · Answer

その可能性を邪魔しないように、iptablesルールを完全にフラッシュしてみませんか。クライアントのiptablesはどうですか？それらも洗い流してください。

iptables --flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables -P FORWARD ACCEPT iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT

次に、クライアントから192.168.0.100にpingを実行しながら、openvpnサーバーでよりクリーンなtcpdumpを実行します。

tcpdump -vn -i tun0 '(Host 192.168.0.100 or Host 10.15.119.6)' and icmp

また、サーバーで2番目のダンプを同時に実行します。

tcpdump -vn -i eth1 '(Host 192.168.0.100 or Host 10.15.119.6)' and icmp

クライアントの3番目のダンプ：

tcpdump -vn -i eth0 Host 192.168.0.100 and icmp

Pingが192.168.0.100に到達し、応答がopenvpnに到達したように見えますが、クライアントには到達していません。しかし、クライアントが返信をドロップしていないことを確認しますか？ 1番目と3番目のtcpdumpはそれを確認します。

Bart De Vos · Answer

私はあなたが求めていることをしました、私はいくつかの異なることをしました。一つには、タップデバイスを使用しました。

以下をご覧ください。

server.conf

port 1194 proto udp dev tap0 ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key # This file should be kept secret dh /etc/openvpn/keys/dh1024.pem ifconfig-pool-persist ipp.txt server-bridge 192.168.220.1 255.255.255.0 192.168.220.90 192.168.220.100 # GATEWAY - NETMASK - START DHCP - END DHCP Push "route 192.168.220.0 255.255.255.0" client-to-client keepalive 10 120 comp-lzo max-clients 20 persist-key persist-tun status openvpn-status.log verb 3

client.conf

remote xxx.xxx.xxx.xxx 1194 udp pull tls-client persist-key ca ca.crt nobind persist-tun cert cert.crt comp-lzo dev tap key key.key resolv-retry infinite

the-wabbit · Answer

サーバー構成ファイルから「up./office.up」を削除して、OpenVPNを再起動してみてください。それは必要ではなく（openvpnデーモンはとにかく「server」ディレクティブによって定義されたネットワークのルートを作成します）、いくつかの失敗はクライアントへのパケットが正しくルーティングされない可能性があります。

Richard Keller · Answer

あなたが達成しようとしているセットアップはやや難解な要求であり、あまりよく知られていないOpenVPNの機能によって対処されます。

ほとんどのVPNセットアップは、VPNサーバーに接続するクライアントがチェーンの最後のリンクであり、VPN上でアクセス可能である必要のある他のコンピューターやネットワークが背後にないように構成されています。シナリオでは、VPNサーバーとVPNクライアントの背後にネットワークがあり、これらのネットワークは相互に直接通信できる必要があります。これを実現するには、いくつかの方法があります。

オプション1：各クライアントでソースNATを構成します。これは、オーバーヘッドを追加するため、推奨されるオプションではありません。クライアント側、および各クライアントをソースNAT用に個別に設定する必要があります。このような設定を多数のネットワークで維持することは悪夢です。

オプション2：OpenVPNが提供するiroutes機能を使用します。 irouteを使用すると、ネットワーク上の各ノードの背後にあるネットワークを明示的に指定できるため、OpenVPNの内部ルーティングを介してさまざまなネットワークが相互に通信できるようになります。ソースよりもirouteを使用する主な利点NATクライアントのオーバーヘッドがなく、構成はすべてVPNサーバーでのみ実行されます。ルートを指定する必要があることに注意してください。 VPNサーバーにプッシュされます-これに加えてirouteの追加を実行する必要があり、各VPNノードの背後にあるネットワーク範囲を定義するという唯一の目的を果たします。

Irouteはささいなトピックではないので、次のページを読むことをお勧めします。 irouteの設定に関して特定の問題がある場合は、ここでそれらの質問をしてください。

http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing http://backreference.org/2009/11/15/openvpn-and- iroute