Я установил сервер openvpn, к которому я могу получить удаленный доступ, после подключения он создает устройство tun0 как на сервере, так и на клиенте с виртуальным ip 10.15.119.x. сам сервер openvpn - 10.15.119.1.
Вопрос: как мне обратиться к другим узлам в локальной сети за сервером openvpn? Я могу получить доступ к службам на самом сервере openvpn с адресом 10.15.119.1:(port), но я не знаю, как обращаться к другим узлам, не участвующим в соединении openvpn, которые находятся в той же локальной сети, что и сервер openvpn: Я надеюсь, что к таким узлам можно будет обращаться с клиентского узла с помощью какого-либо другого виртуального IP-адреса в диапазоне 10.15.119.x, и если это так, мне понадобится только способ узнать, что это за 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
РЕДАКТИРОВАТЬ благодаря wolfgangsz, который заметил опечатку в office.up, я снова попробовал 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-адрес является 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
РЕДАКТИРОВАТЬ 3
Я думаю, что упустил важную информацию, я не думал, что она может быть актуальной, но недавний ответ заставил меня подумать, что это может быть; openvpn напрямую подключен к маршрутизатору, и в конфигурации маршрутизатора (на 192.168.0.1) я включил переадресацию портов для порта openvpn 1194 на сервер openvpn, вот как я сейчас подключаюсь удаленно
РЕДАКТИРОВАТЬ 4
Я пробовал запустить на 192.168.0.100 (вторичный сервер), чтобы посмотреть, смогу ли я решить эту проблему, указав ему маршрут к маршруту 10.15.119.x:
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
я добавил результаты tcpdump на сервере openvpn при попытке пинговать 192.168.0.100 от клиента:
$ 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
Я закомментировал большинство команд DROP и REJECT из iptables, чтобы увидеть, работает ли это, но у меня все еще та же проблема, вот мои 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
как предложил Стивен, я добавил 3 tcpdump, 2 на сервере и один на клиенте, в то время как с клиента запущен
$ 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
но сначала я сбросил все правила iptables на сервере openvpn:
$ 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
вот результат первого tcpdump на сервере openvpn
$ 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
второй 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
и третий 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
ВАЖНЫЙ вот что-то еще, что может быть полезно, на клиенте, который я запускал 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] построено 12 июля 2010 г. Первоначально разработано Джеймсом Йонаном. Авторские права (C ) 2002-2009 OpenVPN Technologies, Inc.
операционная система - Ubuntu 10.10 x86_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) 2) пинг с openvpnserver на 10.15.119.6 (клиент)
что я не могу сделать, так это ping 192.168.0.100 (вторичный сервер LAN) от клиента.
192.168.0.100 действительно отвечает клиенту, как показывает tcpdump на открытом сервере, но каким-то образом эти пакеты не возвращаются обратно клиенту
Попробуй это:
Добавьте на свой сервер правило SNAT iptables.
iptables -t nat -A POSTROUTING -s 10.15.119.0/24 -o eth0 -j SNAT --to-source 10.21.2.118
Это даст любому IP-подключению клиента VPN к другим вашим серверам в этой сети рабочий / маршрутизируемый NAT, к которому можно будет вернуться.
Возможно, я не совсем понимаю, но есть ли у оборудования, к которому вы пытаетесь подключиться за VPN-сервером, настроенный маршрут, который указывает на подсеть клиента OpenVPN?
Если вы используете OpenVPN в системе, которая не является вашим шлюзом по умолчанию и требует отдельного маршрута, эти серверы не смогут возвращать пакеты вашим клиентам.
Пинги, исходящие от вашего сервера OpenVPN, отправляются с интерфейса, к которому оборудование может маршрутизировать, но, возможно, у возвращающихся к клиентам эхо-запросов нет маршрута для возврата, если другие серверы не знают об этом маршруте.
Это может быть неактуально, если вы используете NAT для своего клиентского трафика на сервере, но я не видел ничего, что указывало бы на это в опубликованных вами конфигурациях.
Вам нужно будет протолкнуть маршрут до клиентов. Это делается с помощью опции «push» в файле конфигурации сервера.
По умолчанию сервер 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 будет перенаправлять этот трафик в свое частное соединение Ethernet.
Прочтите страницу руководства OpenVPN (или документацию в Интернете) для получения точных сведений о том, как протолкнуть маршрут.
Я просмотрел ответы и думаю, что разбираюсь в том, где вы со всем этим.
Давайте сделаем несколько простых проверок, чтобы сузить проблему:
От одного из клиентов OpenVPN, который не может проверить связь с хостом 192.168.0.x: netstatn -rn Также дайте нам ifconfig -a для * nix или 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 параметр.
Почему бы вам не очистить правила 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
Затем запустите более чистый tcpdump на сервере openvpn, одновременно отправляя эхо-запрос от клиента на 192.168.0.100:
tcpdump -vn -i tun0 '(host 192.168.0.100 or host 10.15.119.6)' and icmp
Также одновременно запустите второй дамп на сервере:
tcpdump -vn -i eth1 '(host 192.168.0.100 or host 10.15.119.6)' and icmp
Третий дамп на вашем клиенте:
tcpdump -vn -i eth0 host 192.168.0.100 and icmp
Похоже, что ping достигает 192.168.0.100, ответ достигает openvpn, но не вашего клиента. Но уверены ли вы, что клиент не отбрасывает ответ? Первый и третий tcpdump проверит это.
Настройка, которую вы пытаетесь выполнить, - это несколько эзотерический запрос, и он решается функцией OpenVPN, которая не очень хорошо известна.
Большинство настроек VPN настроены таким образом, что клиент, подключающийся к серверу VPN, является последним звеном в цепочке, и за ним нет других компьютеров или сетей, которые должны быть доступны через VPN. В вашем сценарии за VPN-сервером есть сети, а также VPN-клиенты, и эти сети должны иметь возможность напрямую общаться друг с другом. Для этого есть несколько способов:
Опция 1: Настройте исходный NAT на каждом клиенте. Это не лучший вариант, поскольку он увеличивает накладные расходы на стороне клиента, а также требует индивидуальной настройки каждого клиента для NAT источника. Поддерживать такую настройку в большом количестве сетей будет кошмаром.
Вариант 2: Используйте функцию iroutes, предоставляемую OpenVPN. Используя iroutes, вы можете явно указать сети за каждым узлом в сети и, таким образом, позволить различным сетям взаимодействовать друг с другом через внутреннюю маршрутизацию OpenVPN. Основное преимущество использования iroutes по сравнению с исходным NAT заключается в том, что нет накладных расходов на клиента, а вся конфигурация выполняется только на сервере VPN. Имейте в виду, что вам по-прежнему необходимо указывать маршруты, которые будут проталкиваться на VPN-сервер - добавление iroutes должно выполняться в дополнение к этому и служит единственной цели определения диапазонов сети за каждым узлом VPN.
Поскольку iroutes - нетривиальная тема, я советую прочитать следующие страницы. Если у вас есть определенные проблемы с настройкой iroutes, задайте их здесь.
http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing http://backreference.org/2009/11/15/openvpn-and-iroute
Я сделал то, о чем вы просите, кое-что сделал иначе. Во-первых, я использовал ответвитель.
Взгляните ниже:
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
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
Попробуйте удалить «up ./office.up» из файла конфигурации сервера и перезапустить OpenVPN. В этом нет необходимости (демон openvpn в любом случае создаст маршруты для сети, определенной директивой server), и некоторые ошибки могут помешать правильной маршрутизации пакетов вашим клиентам.