6 votes

The Sheek Geek avatar

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

Demandé el 21 de Mai, 2011
Quand la question a-t-elle été
1809 affichage
Nombre de visites la question a
3 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

Réponses

Trop de publicités?

0voto

cde avatar
cde Points 581

La configuration que vous essayez de réaliser est une demande quelque peu ésotérique, et elle est traitée par une fonctionnalité d'OpenVPN qui n'est pas très connue.

La plupart des installations VPN sont configurées de manière à ce que le client qui se connecte au serveur VPN soit le dernier maillon de la chaîne et qu'il n'y ait pas d'autres ordinateurs ou réseaux derrière lui qui doivent être accessibles par le VPN. Dans votre scénario, il y a des réseaux derrière le serveur VPN ainsi que les clients VPN, et ces réseaux doivent pouvoir se parler directement. Il existe plusieurs façons d'y parvenir :

Option 1 : Configurez le NAT source sur chaque client. Ce n'est pas l'option préférée, car elle ajoute de la charge de travail du côté du client et exige que chaque client soit configuré individuellement pour le NAT à la source. La maintenance d'une telle configuration sur un grand nombre de réseaux sera un cauchemar.

Option 2 : Utilisez la fonction iroutes fournie par OpenVPN. En utilisant iroutes, vous pouvez spécifier explicitement les réseaux derrière chaque nœud du réseau, et ainsi permettre aux différents réseaux de communiquer entre eux par le biais du routage interne d'OpenVPN. Le principal avantage de l'utilisation d'iroutes par rapport à la NAT à la source est qu'il n'y a pas de surcharge pour le client et que la configuration s'effectue uniquement sur le serveur VPN. Gardez à l'esprit que vous devez toujours spécifier les routes à pousser sur le serveur VPN - l'ajout d'iroutes doit être effectué en plus de cela et sert uniquement à définir les plages de réseaux derrière chaque nœud VPN.

Les iroutes n'étant pas un sujet trivial, je vous conseille de lire les pages suivantes. Si vous rencontrez des problèmes spécifiques lors de la mise en place d'iroutes, posez vos questions ici.

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

Répondu el 25 de Mai, 2011 par cde (581 Points )

0voto

Bart De Vos avatar
Bart De Vos Points 17611

J'ai fait ce que vous demandez, mais j'ai fait quelques choses différemment. Tout d'abord, j'ai utilisé un dispositif de robinetterie.

Voir ci-dessous :

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
Répondu el 28 de Mai, 2011 par Bart De Vos (17611 Points )

0voto

the-wabbit avatar
the-wabbit Points 40039

Essayez de supprimer le "up ./office.up" de votre fichier de configuration du serveur et redémarrez OpenVPN. Ce n'est pas nécessaire (le démon openvpn créera de toute façon les routes pour le réseau défini par la directive "server") et une erreur quelconque pourrait empêcher les paquets destinés à vos clients d'être acheminés correctement.

Répondu el 31 de Mai, 2011 par the-wabbit (40039 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X