Routage à travers un VPN ... avec OpenVPN

Support Debian
#1

Bonjour,

J’ai monté (au boulot … à droite sur l’image 192.168.222. et 10.) un petit réseau que j’ai relié à mon réseau (chez moi 192.168.0.) grâce à un réseau virtuel (grâce à OpenVPN) :


Cliquez sur l’image pour l’agrandir

Cela marche presque bien …
Le VPN marche bien :
Ca ping du serveur OpenVPN (172.18.0.1) au client OpenVPN (172.18.0.10)

La table de routage du client VPN est bien renseigné car j’ai accès au réseau 192.168.0. depuis le client VPN (et inversement).
C’est d’ailleurs le serveur OpenVPN qui a fournit la route aux clients :

[code]# Push routes to the client to allow it

to reach other private subnets behind

the server. Remember that these

private subnets will also need

to know to route the OpenVPN client

address pool (10.8.0.0/255.255.255.0)

back to the OpenVPN server.

push “route 192.168.0.0 255.255.255.0”
[/code]

Par contre j’aimerais pouvoir accéder au serveur FTP (192.168.222.2) depuis le serveur OpenVPN (et accessoirement depuis mon réseau local 192.168.0. mais ça après je sais faire … configuration de mon routeur NAT … easy) …
… et pour ça il faut que j’ajoute une route sur mon serveur OpenVPN vers le réseau 192.168.222.0 et là c’est le drame !!! :cry:

j’ai essayé ça :

route add 192.168.222.0 gw 172.18.0.1 dev tun0 (marche pas)

ça :

route add 192.168.222.0 gw 172.18.0.2 dev tun0 (marche pas)

ça:

route add 192.168.222.0 gw 172.18.0.10 dev tun0 SIOCADDRT: Aucun processus de ce type

J’ai bien l’impression que c’est un problème de routage mais peut-être que OpenVPN va m’aider à résoudre cela en ‘pushant’ les routes manquantes au serveur lorsque celui-ci se lance ou que le client se connecte …

Je vous mets les ifconfig du serveur et du client

serveur:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1c:23:57:f1:ed
          inet adr:192.168.0.2  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::21c:23ff:fe57:f1ed/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1272282 errors:0 dropped:0 overruns:0 frame:0
          TX packets:742314 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:1779538902 (1.6 GiB)  TX bytes:115237815 (109.8 MiB)
          Interruption:29 Adresse de base:0xe000

lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5487 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5487 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:873656 (853.1 KiB)  TX bytes:873656 (853.1 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet adr:172.18.0.1  P-t-P:172.18.0.2  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1217394 errors:0 dropped:0 overruns:0 frame:0
          TX packets:690053 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:100
          RX bytes:1675749944 (1.5 GiB)  TX bytes:43361940 (41.3 MiB)
client:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:11:09:6e:9e:fc
          inet adr:192.168.222.22  Bcast:192.168.222.255  Masque:255.255.255.0
          adr inet6: fe80::211:9ff:fe6e:9efc/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3706 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3640 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:389675 (380.5 KiB)  TX bytes:417936 (408.1 KiB)
          Interruption:23 Adresse de base:0xec00

eth2      Link encap:Ethernet  HWaddr 00:30:f1:d1:b2:e8
          inet adr:10.0.0.1  Bcast:10.255.255.255  Masque:255.0.0.0
          adr inet6: fe80::230:f1ff:fed1:b2e8/64 Scope:Lien
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:2 dropped:0 overruns:0 carrier:4
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interruption:16 Adresse de base:0xd000

lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:1040 (1.0 KiB)  TX bytes:1040 (1.0 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet adr:172.18.0.10  P-t-P:172.18.0.9  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:284 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:100
          RX bytes:35577 (34.7 KiB)  TX bytes:116845 (114.1 KiB)

Si quelqu’un a une idée ?!

#2

As tu pensé au retour, le serveur FTP sait-il comment atteindre le réseau 172.18.0.0/24

#3

Ça ce n’est pas un problème car sa passerelle c’est ‘client openvpn’ et celui-ci possède dans sa table de routage l’adresse réseau 192.168.0.0.

Le premier test simple que je fais c’est depuis le serveur : Ping 192.168.222.22

Quand cela marchera le rese ne sera que “broutille” de routage.

Merci quand même pour la réponse. Je pensais trouver un spécialiste Openvpn sur ce forum.

#4 
Ça ne va pas. Cela ajoute une route pour l'adresse unique 192.168.222.0. Or tu as besoin d'ajouter une route pour l'adresse unique du serveur 192.168.222.2 ou bien pour son sous-réseau entier 192.168.222.0/24 (masque 255.255.255.0)
[code]route add 192.168.222.2 dev tun0
route add -net 192.168.222.0/24 dev tun0[/code]
(L'interface tun0 est de type IP point à point donc pas besoin de spécifier une passerelle.)

Ça ne va pas. Cela ajoute une route pour l’adresse unique 192.168.222.0. Or tu as besoin d’ajouter une route pour l’adresse unique du serveur 192.168.222.2 ou bien pour son sous-réseau entier 192.168.222.0/24 (masque 255.255.255.0)

route add 192.168.222.2 dev tun0 route add -net 192.168.222.0/24 dev tun0
(L’interface tun0 est de type IP point à point donc pas besoin de spécifier une passerelle.)

#5

je n’ai pas encore les competences requise pour t’aider mais je te donne un lien

olange.developpez.com/articles/d … age_1#LI-B

ceci n’enlevant rien au mérite des helpeurs debian-fr.org

@+

#6

Rien de mieux …

Ce qui est sur c’est que le paquet n’arrive pas jusqu’au client VPN … un tcpdump -i tun0 m’a convaincu !

Je vais poster sur un forum d’openVPN, on verra bien

#7

Si tu manipules tcpdump, tu peux voir à quel moment le paquet part en vrille?

Notamment

  1. Les paquets arrive-t-il au serveur FTP?
  2. Les paquets de réponse arrivent-t-ils au serveur FTP?
  3. As tu pensé aux problèmes usuels sur les serveurs FTP (transfert de port si mode actif et module adequat sur le routeur (i.e client_vpn) si mode passif?

PS: Tu donnes moyen envie de t’aider.

#8

Yes en effet, j’étais bien sur la bonne piste avec cette histoire de route …

Je me trompais pas de beaucoup. Il fallait bien que le client lorsqu’il se connecte “push” les routes au serveur !

J’ai trouvé dans la doc :

[quote]Including multiple machines on the client side when using a routed VPN (dev tun)

In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate (“client2” in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.
First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0 This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0 Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"
This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

Including multiple machines on the client side when using a bridged VPN (dev tap)

This requires a more complex setup (maybe not more complex in practice, but more complicated to explain in detail):

You must bridge the client TAP interface with the LAN-connected NIC on the client.
You must manually set the IP/netmask of the TAP interface on the client.
You must configure client-side machines to use an IP/netmask that is inside of the bridged subnet, possibly by querying a DHCP server on the OpenVPN server side of the VPN.
[/quote]

et ça marche du tonnerre !

#9

Salut,

Alors n’oublie pas la coche verte plutôt que RESOLU !

#10

loukoum, pourrais-tu mettre la conf de tes serveurs stp? J’essaie de faire la même chose mais je bloque au niveau du routage.
Je voudrais juste avec la conf des “push route” ainsi que "iptables masquerade"
Merci d’avance…

#11

Coté Serveur

debian:~# cd /etc/openvpn/

debian:/etc/openvpn# l
total 48K
-rw-r--r-- 1 root root 1,2K 29 oct.  21:55 ca.crt
-rw------- 1 root root  887 29 oct.  21:55 ca.key
drwxr-xr-x 2 root root 4,0K 24 mars  23:31 ccd
-rw-r--r-- 1 root root  245 29 oct.  21:55 dh1024.pem
-rw------- 1 root root   35 13 avril 13:31 ipp.txt
-rw------- 1 root root  509 13 avril 13:39 openvpn-status.log
-rw-r--r-- 1 root root  11K 24 mars  23:31 server.conf
-rw-r--r-- 1 root root 3,7K 29 oct.  21:55 server.crt
-rw------- 1 root root  887 29 oct.  21:55 server.key
-rwxr-xr-x 1 root root 1,4K 18 sept.  2008 update-resolv-conf

debian:/etc/openvpn# l ccd/
total 4,0K
-rwxrwxrwx 1 root root 36 24 mars  23:31 Client01

debian:/etc/openvpn# cat ccd/Client01
iroute 192.168.222.0 255.255.255.0

debian:/etc/openvpn# cat server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
dh dh1024.pem
server 172.18.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
client-config-dir ccd
route 192.168.222.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.x.x.x"
push "dhcp-option DNS 208.x.x.x"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Coté Client

bill:~# cd /etc/openvpn/
bill:/etc/openvpn# l
total 20K
-rwxrwxrwx 1 root root 1,2K oct 29 22:53 ca.crt
-rwxrwxrwx 1 root root 3,6K mar 21 20:10 Client01.crt
-rwxrwxrwx 1 root root  887 mar 21 20:10 Client01.key
-rwxrwxrwx 1 root root 3,4K mar 22 11:22 client.conf
-rwxr-xr-x 1 root root 1,4K sep 18  2008 update-resolv-conf

bill:/etc/openvpn# cat client.conf
client
dev tun
proto udp
remote 88.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Client01.crt
key Client01.key
ns-cert-type server
comp-lzo
verb 3

bill:/etc/openvpn# cat Client01.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4 (0x4)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=FR, L=AIN, O=Fort-Funston, CN=server/emailAddress=me@myhost.mydomain
        Validity
            Not Before: Mar 21 19:10:35 2011 GMT
            Not After : Mar 18 19:10:35 2021 GMT
        Subject: C=FR, ST=CA, L=BELLIGNAT, O=EN, OU=SEN, CN=Client01/emailAddress=me@myhost.mydomain
        Subject Public Key Info:
        .......... etc etc etc ................

Voilà

… J’ai trouver les infos ici : openvpn.net/index.php/open-sourc … html#scope

Bon courage