Problème OpenVPN en Bridge

Bonjour !

Je me permet de vous exposer un petit souci que je rencontre : je souhaite mettre en place un Serveur VPN sur un poste en Debian Squeeze.
J’aimerais qu’un client, à partir d’Internet, puisse se connecter au serveur VPN et ainsi accéder aux ressources présentes sur le LAN du Serveur VPN.
Dans un premier temps et par souci de sécurité, je fais mes tests sans être connecté au net, en local.

Voici l’existant :

  1. Le serveur
    Il a deux interfaces réseaux :
  • 172.16.0.250 masque 255.0.0.0 , cette carte est connectée au reste du LAN du serveur
  • l’IP publique
  1. Le client
    Windows XP SP3 / OpenVPN Client / Pare-feu désactivé

  2. Les fichiers de conf:

/etc/network/interfaces


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address 172.16.0.250
	netmask 255.0.0.0
	gateway 172.16.0.1
	dns-nameservers 172.17.0.15

auto eth1
iface eth1 inet static
	address [IP PUBLIQUE]
        netmask 255.255.255.248
        gateway [PASSERELLE]

Voici le résultat d’un ifconfig

ifconfig

br0       Link encap:Ethernet  HWaddr 00:1a:a0:0a:d0:e8
          inet adr:172.16.0.250  Bcast:172.255.255.255  Masque:255.0.0.0
          adr inet6: fe80::21a:a0ff:fe0a:d0e8/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2387 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2005 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:138668 (135.4 KiB)  TX bytes:151919 (148.3 KiB)

eth0      Link encap:Ethernet  HWaddr 00:1a:a0:0a:d0:e8
          adr inet6: fe80::21a:a0ff:fe0a:d0e8/64 Scope:Lien
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:9648 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7855 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:743889 (726.4 KiB)  TX bytes:614901 (600.4 KiB)
          Interruption:21

eth1      Link encap:Ethernet  HWaddr []
          inet adr:[IP PUBLIQUE]  Bcast:[]  Masque:255.255.255.248
          adr inet6: [] Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33418 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28972 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:2847266 (2.7 MiB)  TX bytes:2787467 (2.6 MiB)
          Interruption:21 Adresse de base:0x8f00

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:77593 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77593 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:6526234 (6.2 MiB)  TX bytes:6526234 (6.2 MiB)

tap0      Link encap:Ethernet  HWaddr 2e:6e:27:eb:29:58
          adr inet6: fe80::2c6e:27ff:feeb:2958/64 Scope:Lien
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:514 overruns:0 carrier:0
          collisions:0 lg file transmission:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Ci dessous les scripts d’ouverture/fermeture du bridge
/etc/openvpn/scripts/bridge-start

#!/bin/bash
br="br0"
tap="tap0"
eth="eth0"
eth_ip="172.16.0.250"
eth_netmask="255.0.0.0"
eth_broadcast="172.255.255.255"
for t in $tap; do
    openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
    brctl addif $br $t
done
for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

/etc/openvpn/scripts/bridge-stop

#!/bin/bash
br="br0"
tap="tap0"
ifconfig $br down
brctl delbr $br
for t in $tap; do
    openvpn --rmtun --dev $t
done

Voici le fichier de configuration du server VPN :
/etc/openvpn/server.conf

port 1194
proto udp
dev tap
ca ca.crt
cert [NOM_CERTIFICAT].crt
key [NOM_CERTIFICAT].key  
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 172.16.0.50 255.0.0.0 172.20.0.10 172.20.0.100
push "route 172.16.0.0 255.0.0.0"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Et la configuration du client: (fichier .ovpn)

client
dev tap0
proto udp
remote [IP_PUBLIQUE] 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
  1. le pare-feu
# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A fail2ban-ssh -j RETURN
  1. Le souci rencontré

Après le bridge-start, je lance le serveur VPN avec la commande

openvpn server.conf

Voici le résultat :

Tue Dec 27 15:42:16 2011 OpenVPN 2.1.3 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Oct 21 2010
Tue Dec 27 15:42:16 2011 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Tue Dec 27 15:42:16 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Dec 27 15:42:16 2011 Diffie-Hellman initialized with 1024 bit key
Tue Dec 27 15:42:16 2011 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Tue Dec 27 15:42:17 2011 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Dec 27 15:42:17 2011 Socket Buffers: R=[112640->131072] S=[112640->131072]
Tue Dec 27 15:42:17 2011 TUN/TAP device tap1 opened
Tue Dec 27 15:42:17 2011 TUN/TAP TX queue length set to 100
Tue Dec 27 15:42:17 2011 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Dec 27 15:42:17 2011 UDPv4 link local (bound): [undef]
Tue Dec 27 15:42:17 2011 UDPv4 link remote: [undef]
Tue Dec 27 15:42:17 2011 MULTI: multi_init called, r=256 v=256
Tue Dec 27 15:42:17 2011 IFCONFIG POOL: base=172.20.0.10 size=91
Tue Dec 27 15:42:17 2011 IFCONFIG POOL LIST
Tue Dec 27 15:42:17 2011 alexandre,172.20.0.10
Tue Dec 27 15:42:17 2011 Initialization Sequence Completed

Maintenant, côté client, je lance OpenVPN sur Windows, je n’ai pas d’erreurs côté serveur sur la console.
L’IP attribuée au client est 172.20.0.10, mais à partir du Serveur je ne peux pas pinger cette adresse…

Aurais-je loupé quelque chose ?

J’espère que vous serez indulgents, je ne suis pas un pro de Debian.

Merci d’avance pour vos remarques/commentaires

Xanderz

Plus précisément, où est le client, sur quel réseau, avec quelle adresse ?

[quote=“Xanderz”]1) Le serveur
Il a deux interfaces réseaux :

  • 172.16.0.250 masque 255.0.0.0[/quote]
    Pas bon : il y a plein d’adresses publiques dans ce bloc, qui deviennent inaccessibles si tu dis à ton serveur que tout ça est sur le LAN. La plage d’adresses privées dans ce bloc est seulement 172.16.0.0/12 (masque 255.240.0.0).

En clair, ça veut dire quoi ? Il y a un message d’erreur, tu as fait une capture de paquets pour voir ce qui se passe sur les interfaces ?

Plus précisément, où est le client, sur quel réseau, avec quelle adresse ?[/quote]
Au temps pour moi, ce n’était pas clair :

Le PC Client: 46.35… (ip publique) est branché par un simple câble réseau sur eth1 du Serveur (le Serveur a une adresse publique également en 46.35…)

Actuellement sur notre LAN nous avons des machines en 172.16 , ou encore en 172.X où X>16, et leur masque est de 255.0.0.0 sur nos postes de travail. En effet le masque est mal positionné, nous règlerons ce souci.

[quote=“PascalHambourg”]

En clair, ça veut dire quoi ? Il y a un message d’erreur, tu as fait une capture de paquets pour voir ce qui se passe sur les interfaces ?[/quote]

En clair j’essaye de faire un ping 172.20.0.10 (IP VPN du client) sur la console du Serveur, et voici la réponse :

From 172.16.0.250 icmp_seq=1 Destination Host Unreachable

Il faut que j’installe tcpdump, et que je regarde comment ça marche pour faire une capture de paquets.
Je poste le résultat, par contre vu que je ne sais pas ce que je recherche comme type d’info ça risque d’être assez volumineux.

Merci beaucoup en tout cas pour ces remarques

En attendant les captures, une fois le tunnel monté il serait intéressant de fournir les sorties de ip addr et ip route sur le serveur et ipconfig et route print sur le client.

Je suis en train de rapatrier les sorties de ces différentes commandes.
Dans le résultat de ip addr je trouve beaucoup d’adresses ip publiques, ipv4 et ipv6, j’ai peur qu’en masquant toutes ces adresses, le fichier soit inutilisable… tant pis dans un premier temps je l’envoie quand même comme ça, au pire tu me diras si j’ai masqué trop d’informations…

Côté Client Windows :

ipconfig

Configuration IP de Windows


Carte Ethernet Connexion au réseau local:

        Suffixe DNS propre à la connexion :
        Adresse IP. . . . . . . . . . . . : [ADRESSE_IP_PUBLIQUE]
        Masque de sous-réseau . . . . . . : 255.255.255.248
        Passerelle par défaut . . . . . . : [PASSERELLE_PUBLIQUE]

Carte Ethernet Connexion au réseau local 9:

        Suffixe DNS propre à la connexion :
        Adresse IP. . . . . . . . . . . . : 172.20.0.10
        Masque de sous-réseau . . . . . . : 255.0.0.0
        Passerelle par défaut . . . . . . :

route print :

===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 19 b9 54 08 29 ...... Broadcom NetXtreme 57xx Gigabit Controller - Min
iport d'ordonnancement de paquets
0x3 ...00 ff 55 d5 68 42 ...... TAP-Win32 Adapter OAS - Miniport d'ordonnancemen
t de paquets
===========================================================================
===========================================================================
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0     [PASSERELLE_PUBLIQUE]    [ADRESSE_IP_PUBLIQUE]       10
     46.35.25.184  255.255.255.248     [ADRESSE_IP_PUBLIQUE]    [ADRESSE_IP_PUBLIQUE]       10
     [ADRESSE_IP_PUBLIQUE]  255.255.255.255        127.0.0.1       127.0.0.1       10
   46.255.255.255  255.255.255.255     [ADRESSE_IP_PUBLIQUE]    [ADRESSE_IP_PUBLIQUE]       10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        172.0.0.0        255.0.0.0      172.20.0.10     172.20.0.10       30
      172.20.0.10  255.255.255.255        127.0.0.1       127.0.0.1       30
   172.20.255.255  255.255.255.255      172.20.0.10     172.20.0.10       30
        224.0.0.0        240.0.0.0     [ADRESSE_IP_PUBLIQUE]    [ADRESSE_IP_PUBLIQUE]       10
        224.0.0.0        240.0.0.0      172.20.0.10     172.20.0.10       30
  255.255.255.255  255.255.255.255     [ADRESSE_IP_PUBLIQUE]    [ADRESSE_IP_PUBLIQUE]       1
  255.255.255.255  255.255.255.255      172.20.0.10     172.20.0.10       1
Passerelle par défaut :      [PASSERELLE_PUBLIQUE]
===========================================================================
Itinéraires persistants :
  Adresse réseau    Masque réseau  Adresse passerelle Métrique
         10.0.0.0        255.0.0.0      192.168.1.2       1

Côté serveur :

#ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether [] brd ff:ff:ff:ff:ff:ff
    inet [IP_PUBLIQUE_SERVEUR]/29 brd [] scope global eth1
    inet6 []
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether [] brd ff:ff:ff:ff:ff:ff
    inet6 []/64 scope link
       valid_lft forever preferred_lft forever
5: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether [] brd ff:ff:ff:ff:ff:ff
31: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether [] brd ff:ff:ff:ff:ff:ff
    inet6 []/64 scope link
       valid_lft forever preferred_lft forever
32: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether []< brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.250/8 brd 172.255.255.255 scope global br0
    inet6 []/64 scope link
       valid_lft forever preferred_lft forever
33: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 100
    link/ether [] brd ff:ff:ff:ff:ff:ff

ip route

[]/29 dev eth1  proto kernel  scope link  src [IP_PUBLIQUE_SERVEUR]
172.0.0.0/8 dev br0  proto kernel  scope link  src 172.16.0.250
default via [] dev eth1

Quelle est cette interface tap1 sur le serveur ? Ne serait-ce pas celle-là qui est le bout du tunnel au lieu de tap0 ? tap0 est créée et pontée par le script /etc/openvpn/scripts/bridge-start mais dans le fichier de configuration /etc/openvpn/server.conf il n’y a que “dev tap”. Se pourrait-il qu’openvpn voie que tap0 existe déjà et crée tap1 ? Dans ce cas ne faudrait-il pas spécifier “dev tap0” ?

Arf, exact, celle-là m’avait bien échappé… Merci beaucoup je sens que j’aurais pu chercher un moment…
Je viens de modifier le server.conf, relancer le serveur, les pings passent : à partir du PC Windows (client VPN) je ping une machine présente sur le réseau local du serveur VPN, et le serveur VPN ping à son tour le client VPN.

Bref, les ping passent, c’est déjà ça, maintenant je vais essayer de joindre différents serveurs (mail, ftp, web) sur le réseau local du serveur VPN à partir de clients VPN.

Bon, pour cette semaine je vais pas pouvoir avancer plus, je pars en vacances et rentrerais jeudi prochain.
Je posterais le résultat de mes tests dès que possible, encore merci et bonnes fêtes !

Bah, pourquoi ? J’ai bien eu l’idée alors que je n’ai encore jamais utilisé openvpn (ouais, j’avoue).

Au niveau IP ça devrait bien se passer puisque le ping passe. Par contre il peut y avoir une difficulté au niveau de la résolution DNS, si les DNS par défaut des clients ne savent pas résoudre les noms des serveurs privés de ton réseau local. Dans ce cas il faudrait leur “pousser” un serveur DNS de ton réseau local, mais ce dernier ne serait pas forcément capable de résoudre les noms des serveurs des réseaux des clients.

Bonjour et bonne année…
Oui je confirme mes tests ont été concluants. Il ne me reste plus qu’à passer une route via le Serveur VPN, aux clients, afin qu’ils puissent atteindre un autre réseau en 10.X

Merci beaucoup encore !