opvnvpn : adressage des nœuds dans les LAN-behinds

Question

opvnvpn : adressage des nœuds dans les LAN-behinds

Demandé el 21 de Mai, 2011: Quand la question a-t-elle été
1808 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

J'ai mis en place un serveur openvpn auquel je peux accéder à distance, une fois connecté, il crée un périphérique tun0 sur le serveur et le client avec l'ip virtuelle 10.15.119.x. Le serveur openvpn est lui-même 10.15.119.1.

Pregunta: Comment adresser d'autres noeuds dans le réseau local derrière le serveur openvpn ? Je peux accéder aux services sur le serveur openvpn lui-même avec l'adresse 10.15.119.1 :(port), mais je ne sais pas comment adresser d'autres noeuds qui ne participent pas à la connexion openvpn et qui se trouvent dans le même réseau local que le serveur openvpn : J'espère que ces nœuds peuvent être adressés à partir du nœud client avec une autre adresse IP virtuelle dans la plage 10.15.119.x, et si c'est le cas, j'aurais seulement besoin d'un moyen de savoir quelles sont ces adresses IP.

Je pourrais très bien créer des commandes iptables et route pour transférer des ports vers d'autres nœuds spécifiques, mais je suis sûr qu'il doit y avoir une façon plus agréable de le faire, en s'adressant directement aux nœuds.

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

le script office.up script a :

#!/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 à la place :

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

Nouveau les journaux pertinents du serveur :

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]

les journaux pertinents du client :

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 grâce à wolfgangsz qui a remarqué une faute de frappe dans le office.up, j'ai réessayé tracepath sans amélioration :

$ 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

Notez la différence de résultat lorsque l'adresse IP est celle du serveur 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

les entrées de routage chez le client :

$ 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

et les entrées de routage sur le serveur (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

EDIT 2 : J'ai vérifié que la redirection d'ip est activée.

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

Voici la sortie de l'iptables sur le serveur :

$ 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

EDIT 3

je pense que j'ai oublié une information importante, je ne pensais pas qu'elle serait pertinente, mais une réponse récente m'a fait penser qu'elle pourrait l'être ; l'openvpn est directement connecté au routeur, et dans la configuration du routeur (à 192.168.0.1) j'ai activé le transfert de port pour le port 1194 de l'openvpn vers le serveur openvpn, c'est ainsi que je me connecte actuellement à distance

EDIT 4

J'ai essayé d'exécuter ce qui suit sur le système 192.168.0.100 (serveur secondaire), afin de voir si je peux résoudre ce problème en lui donnant une route vers la route 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 est l'adresse du serveur openvpn, 192.168.0.100 est le serveur secondaire que je veux atteindre de l'extérieur)

J'ai essayé ceci et ping 10.15.119.1 fonctionne pour atteindre le serveur openvpn, mais ping 10.15.119.6 (l'ip de mon client) échoue

EDIT 5

J'ai ajouté les résultats de tcpdump sur le serveur openvpn lorsqu'on essaie d'envoyer un ping à 192.168.0.100 depuis le client :

$ 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

Il semble que les ping atteignent le serveur et qu'il réponde, mais les paquets sont rejetés avant d'entrer dans le vpn, j'ai donc ajouté une ligne dans iptables pour enregistrer tous les paquets INPUT et FORWARD rejetés ou abandonnés. et voici ce qui est filtré /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

J'ai commenté la plupart des commandes DROP et REJECT d'iptables pour voir si cela fonctionne, mais j'ai toujours le même problème, voici mon iptables après avoir supprimé tous les drops

$ 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

EDIT 6

comme suggéré par Steven, j'ai ajouté 3 tcpdumps, 2 sur le serveur et un sur le client, alors que depuis le client, j'exécute

$ 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

Mais j'ai d'abord nettoyé toutes les règles iptables sur le serveur 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

voici la sortie du premier tcpdump sur le serveur 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

un second tcpdump sur le serveur :

$ 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

et un troisième tcpdump, cette fois sur le client :

$ 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 Voici un autre élément qui pourrait s'avérer utile, pour le client que j'ai dirigé 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

même commande sur le serveur 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

version d'openvpn :

$ openvpn --version OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] construit le Jul 12 2010 Développé à l'origine par James Yonan Copyright (C) 2002-2009 OpenVPN Technologies, Inc.

le système d'exploitation est Ubuntu 10.10 x86_64

Pourquoi est-ce que j'obtiens sur le journal du client :

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

Qu'en est-il du masque 255.255.255.255 pour le réseau virtuel ?

@skrewler, voici le résultat de netstat :

d'abord, à partir du client lorsque l'openvpn est en cours d'exécution :

$ 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)

et le fichier 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

deuxièmement, à partir du serveur 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

Avec la configuration ci-dessus, je suis en mesure de :

1) ping du client vers 192.168.0.101 (le serveur openvpn) 2) ping du serveur openvpn vers 10.15.119.6 (le client)

Ce que je ne peux pas faire, c'est envoyer un ping à 192.168.0.100 (serveur LAN secondaire) à partir du client.

192.168.0.100 répond effectivement au client comme le montre tcpdump sur l'openserver, mais d'une manière ou d'une autre, ces paquets ne sont pas renvoyés au client.

Demandé el 21 de Mai, 2011 par The Sheek Geek

Answer 1

5 Réponses

Answer 2

2voto

Lawrence Points 203

Vous devrez faire passer un itinéraire aux clients. Cela se fait en utilisant l'option "push" dans le fichier de configuration du serveur.

Par défaut, le serveur OpenVPN n'envoie qu'une route vers lui-même.

En général, lors de la mise en place d'un serveur VPN, il est conseillé de faire fonctionner le VPN sur un sous-réseau distinct, afin de faciliter le routage et la configuration du pare-feu. Exemple :

Le serveur qui exécute le serveur OpenVPN a une adresse IP interne de 10.15.119.1. Son adresse IP publique est 123.1.2.3. Et l'ensemble de votre réseau interne est sur 10.15.119.0/24. Vous devez donc configurer le serveur OpenVPN pour qu'il fonctionne sur 10.15.120.0/24, ce qui vous donnera jusqu'à 63 connexions clients possibles (chaque connexion nécessite un petit sous-réseau de 4 adresses IP). Le premier client qui se connecte recevra l'adresse IP 10.15.120.5. Si vous poussez maintenant la route vers 10.15.119.0/24 , le client ajoutera une route à sa table de routage afin que tout le trafic de ce sous-réseau passe dans le tunnel. Le serveur OpenVPN transmettra alors ce trafic à sa connexion Ethernet privée.

Lisez la page de manuel d'OpenVPN (ou la documentation sur l'internet) pour obtenir les détails exacts sur la manière de pousser une route.

Répondu el 21 de Mai, 2011 par Lawrence (203 Points )

Answer 3

2voto

Magellan Points 4431

Je n'ai peut-être pas bien compris, mais l'équipement que vous essayez d'atteindre derrière le serveur VPN a-t-il une route configurée qui pointe vers le sous-réseau du client OpenVPN ?

Si vous utilisez OpenVPN sur un système qui n'est pas votre passerelle par défaut et qui nécessite une route distincte, ces serveurs ne seront pas en mesure de renvoyer des paquets à vos clients.

Les pings provenant de votre serveur OpenVPN sont envoyés à partir d'une interface vers laquelle l'équipement peut se diriger, mais les pings retournant vers les clients n'ont peut-être pas de route pour revenir si les autres serveurs ne connaissent pas cette route.

Cela peut ne pas être pertinent si vous NATez votre trafic client sur le serveur, mais je n'ai rien vu qui l'indique dans les configurations que vous avez postées.

Répondu el 27 de Mai, 2011 par Magellan (4431 Points )

Answer 4

2voto

skrewler Points 288

J'ai parcouru les réponses et je pense que je suis en mesure de comprendre où vous en êtes avec tout cela.

Effectuons quelques vérifications simples pour limiter le problème :

Depuis l'un des clients OpenVPN qui n'est pas en mesure d'envoyer un ping à un hôte 192.168.0.x : netstatn -rn Donnez-nous également ifconfig -a pour *nix ou ipconfig /all ping <openvpn server external 10.21.x address> ping <openvpn 10.15.x address

Depuis le serveur openvpn : netstatn -rn ping <a 192.168.0.x host> ping <a 10.15.x host> ping <a 10.21.x host>

De plus, la configuration actuelle de votre serveur openvpn et de votre client se trouve probablement à /etc/openvpn/server.conf et sur la machine cliente /etc/openvpn/<hostname>.conf o c:\program files\openvpn\config\<hostname.conf> or .ovpn

J'ai une configuration similaire. Sur mon serveur OpenVPN, j'ai l'équivalent de cette règle iptables (j'ai changé hostmask/interface pour les valeurs que vous devriez avoir) :

# 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

Il semble que votre problème soit certainement dû au fait qu'il vous manque 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 ou essayez avec le -a paramètre.

Répondu el 31 de Mai, 2011 par skrewler (288 Points )

Answer 5

2voto

dmourati Points 24230

Essayez ceci :

Ajoutez une règle iptables SNAT sur votre serveur.

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

Cela permettra à toutes les connexions IP des clients VPN vers les autres serveurs de ce réseau de bénéficier d'un NAT fonctionnel/routé.

Répondu el 1 de Juin, 2011 par dmourati (24230 Points )

Answer 6

1voto

Steven Points 2979

Pourquoi ne pas supprimer complètement les règles iptables, afin d'éliminer cette possibilité. Qu'en est-il des règles iptables sur le client ? Videz-les également.

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

Ensuite, lancez un tcpdump plus propre sur le serveur openvpn, tout en faisant un ping depuis le client vers 192.168.0.100 :

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

Exécutez également une deuxième vidange sur le serveur en même temps :

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

Une troisième décharge sur votre client :

tcpdump -vn -i eth0 host 192.168.0.100 and icmp

Il semble que le ping atteigne 192.168.0.100, que la réponse atteigne openvpn, mais pas votre client. Mais êtes-vous sûr que le client ne laisse pas tomber la réponse ? Le premier et le troisième tcpdump le vérifieront.

Répondu el 30 de Mai, 2011 par Steven (2979 Points )

opvnvpn : adressage des nœuds dans les LAN-behinds

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

opvnvpn : adressage des nœuds dans les LAN-behinds

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: