Install openvpn en mode bridge

Trucs et Astuces
#21

Bon, alors je me lance mais ça rique d’être long.

Je ne sais pas trop par où commencer pour expliquer ma totale incompréhension des interfaces réseau sous linux. Entre tap(x)/tn(x), eth(x) et br(x) je ne vois vraiment pas qui fait quoi ni pourquoi. Je suis en train de faire des essais sur un réseau interne 192.168.0/24. Le serveur (sans openvpn) a un interfaces classique avec une ip statique.

auto lo eth0
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.158
netmask 255.255.255.0
network 192.168.0.0 
broadcast 192.168.0.255
gateway 192.168.0.1

Ce qui donne comme interfaces:

eth0      Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          inet adr:192.168.0.158  Bcast:192.168.0.255  Masque:255.255.255.0
lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0

Je lance l’openVPN avec la config du sample-config-files d’openvpn:

port 1194
proto udp
dev tap

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun

status openvpn-status.log
log-append  /var/log/openvpn.log
verb 3

et j’obtiens:

eth0      Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          inet adr:192.168.0.158  Bcast:192.168.0.255  Masque:255.255.255.0
lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
tap0      Lien encap:Ethernet  HWaddr 5A:D7:43:F7:9A:4D  
          inet adr:10.8.0.1  Bcast:10.8.0.255  Masque:255.255.255.0

Avec une table de routage:

Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
10.8.0.0        *               255.255.255.0   U     0      0        0 tap0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Depuis un client openvpn, je parviens à pinger 10.8.0.1
Je suppose que le tunnel VPN fonctionne donc.

Maintenant en mode bridge. Configuration bridge de Mat avec les variantes de fran.b là, c’est un peu le b…

Dans le server.conf j’ai mis

server-bridge 192.168.0.158  255.255.255.0  192.168.0.151  192.168.0.250

où
(...158 est l’ip statique de mon serveur) et modifié mon fichier interfaces et ajouté les scripts ovup et ovdown en ajoutant juste une ligne
gateway (192.168.0.1)
dans interfaces :

port 1194
proto udp
dev tap0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.0.158 255.255.255.0 192.168.0.151 192.168.0.250
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append  /var/log/openvpn.log
verb 5 

auto lo br0 
iface lo inet loopback

# Fichier interfaces

iface br0 inet static
address 192.168.0.158
netmask 255.255.255.0
gateway 192.168.0.1
broadcast 192.168.0.255
bridge-ports eth0
post-up /etc/openvpn/scripts/ovup && /etc/init.d/openvpn start
pre-down /etc/init.d/openvpn stop
post-down /etc/openvpn/scripts/ovdown


# script ovup
#!/bin/sh
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig eth0 promisc up
ifconfig tap0 promisc up
ifconfig br0 192.168.0.158 netmask 255.255.255.0 broadcast 192.168.0.255

Après lancement, Ifconfig du serveur.

br0       Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          inet adr:192.168.0.158  Bcast:192.168.0.255  Masque:255.255.255.0
eth0      Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          adr inet6: fe80::20c:f1ff:feca:593/64 Scope:Lien
lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
tap0      Lien encap:Ethernet  HWaddr 6A:57:0C:C9:21:74  
          adr inet6: fe80::6857:cff:fec9:2174/64 Scope:Lien

Ici, déjà tap0 et eth0 du serveur n’ont pas d’adresse IP.

Si sur un client linux je lance openvpn client.conf j’ai le warning suivant:

 --remote address [192.168.0.158] conflicts with --ifconfig subnet [192.168.0.151, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet.

et, dans l’ifconfig du client le tap0 suivant vient s’ajouter:

tap0      Link encap:Ethernet  HWaddr 00:ff:a6:11:23:eb  
          inet adr:192.168.0.151  Bcast:192.168.0.255  Masque:255.255.255.0

Quand je ping 192.168.0.151 ou que je me connecte en ssh sur cette ip, je reviens sur la machine client dont la table de routage est devenue:

Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 tap0
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Bref, je me rends compte que j’ai de sérieux efforts à faire pour comprendre les interfaces réseau et ce qui s’en suit… J’y travaille mais, avec votre aide, ça ira plus vite :=)

#23

Bon, je suis un peu pressé, mais il y a un truc, déjà à comprendre,
c’est qu’une fois intègrées au bridge par le script ovup,
tu peux complètement oublier eth0 et tap0 qui n’existent plus pour le réseau.

Seul le bridge reste en tant qu’interface, et il écoute à la fois sur eth0 et sur tap0 en connectant les deux LANs comme s’ils n’en faisaient plus qu’un (tu peux d’ailleurs avoir -dans d’autres cas que le vpn - des bridges transparents sans adresse IP, même si c’est pas forcément pratique à administrer à distance, dans ce cas).
Sinon, je me plongerais dans ton pb plus tard.

#24

J’ai un début de piste. Sorti du howto d’openvnp.net

Déjà là je me suis planté.

Ensuite je reprends la piste du mode routed qui semble permettre de mieux filtrer les clients:

Pas mal tâtonné en raison de ma méconnaissance des commandes de configuration d’interface réseau.

server.conf

# mode routed
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 5

/etc/network/interfaces

auto lo br0 
iface lo inet loopback

iface br0 inet static
address 192.168.0.158
netmask 255.255.255.0
broadcast 192.168.0.255
bridge-ports eth0
post-up /etc/openvpn/scripts/ovup.routed 
post-down /etc/openvpn/scripts/ovdown.routed
gateway 192.168.0.1

ovup.routed

#!/bin/sh
/etc/init.d/openvpn start
openvpn --mktun --dev tun0P
ifconfig tun0 0.0.0.0 promisc up
#brctl addif br0 tun0   # provoquait une erreur
ifconfig br0 192.168.0.158 netmask 255.255.255.0 broadcast 192.168.0.255 up
/etc/init.d/openvpn force-reload

Ici j’ai été obligé de faire un force-relaod d’openvpn sans quoi aucune IP n’était attribuée à tun0. De plus j’ai supprimé le brtcl… qui me sortait une erreur (explication?).

ovdown.routed

/etc/init.d/openvpn stop
# openvpn --rmtun --dev tun0

Ne contient que l’arrêt d’openvpn. Je confirme ce que disait fran.b plus haut.
Le remove de tun0 est non seulement inutile ça me laissait mes interfaces dans un état qui ne permettait pas redémarrage correct par /etc/init.d/networking restart.
Pas compris pourquoi mais ça marche mieux sans.

Voici le résultat d’un ifconfig (résumé) du serveur:

br0       Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          inet adr:192.168.0.158  Bcast:192.168.0.255  Masque:255.255.255.0
eth0      Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          adr inet6: fe80::20c:f1ff:feca:593/64 Scope:Lien
lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
tun0      Lien encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet adr:10.8.0.1  P-t-P:10.8.0.2  Masque:255.255.255.255

Est-ce que tout ça vous semble correct?
Si j’ai bien compris, br0 est une “interface virtuelle” qui pointe vers l’interface physique eth0 c’est bien ça?

#25

Ben c’est correct si ça fonctionne, je n’ai pas vraiment lu, mais tu t’es pris la tête.
Pour le mode bridge, tu dois passer par script ifup pour lancer openvpn seulement une fois que tu as constitué le bridge, d’ou la necessité d’un tuto, mais pour le mode routé sous debian, tu installes le paquet openvpn, tu fais un server.conf, et c’est tout.

Par ailleurs pour faire du filtrage sur un bridge, tu as moyen d’utiliser le physdev (à voir dans le man d’iptables), ce qui ne te permet pas tout, mais le plus souvent, c’est suffisant pour faire ce qu’on a à faire comme filtrage de base.
Dommage. Mais bon, ça te permet de lire de la doc. :laughing:

#26

je viens de voir que tu avais encore un bridge,
en plus de faire des réflexes ifup, dans ta mise en oeuvre du mode routé.

C’est pas bon: c’est soit le bridge en mode bridgé (et le tuto est bon, si effectivement les adresses de ton vpn ne sont pas celles utilisées à un bout ou l’autre du vpn), et pour le mode routé, pas de bridge du tout.

Tu fais juste du forwarding entre tun0 et eth0 pour faire circuler les paquets dans ce cas.

#27

Je n’ai décidemment pas compris la fonction de br0 et des bridge non?
J’ai viré toute référence à br0 dans les fichiers interfaces et autres srcipts ovup
et un network restart plus loin, ça me donne ceci:

eth0      Lien encap:Ethernet  HWaddr 00:0C:F1:CA:05:93  
          inet adr:192.168.0.158  Bcast:192.168.0.255  Masque:255.255.255.0
lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
tun0      Lien encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet adr:10.8.0.1  P-t-P:10.8.0.2  Masque:255.255.255.255

C’est mieux? En tous les cas, ça marche.
Et le forwarding entre tun0 et eth0, ça se passe comment? Où est-ce défini dans les fichiers des interfaces?

#28

Alors en mode routé, maintenant, tu te retrouve comme si tu avais un lan composé de tes clients qui ont comme passerelle ton tun0, et que tu voulais leur donner accés à l’internet (le lan sur lequel est eth0).
Tu dois activer le forwarding (forum.webnetters.org/bar/activer … -1755.html), et aprés, tu choisis avec iptables ce que tu transmet ou pas.

#29

OK, ça roule. Merci.

#30

Je profite de ce sujet pour poser une question VPN. Quelqu’un connait-il une méthode pour se connecter à un VPN géré par Checkpoint sur lequel l’identification se fait par login + mot de passe + fob securID ? De ce que j’ai lu jusque là, OpenVPN semble être capable de le faire mais j’y comprend pas grand chose dans les certificats CA, PKCS 11 ( ou 12 ) et autres joyeusetés.
Donc si par hasard quelqu’un ici peut ne serait-ce que m’éclairer un peu sur la démarche globale, ça me permettrait de gland^W travailler depuis chez moi sous nunux, et sans plus passer par cette machine virtuelle windows que j’utilise actuellement.

#31

J’ai beau avoir écrit ce tuto, je ne suis pas top non plus. Et en cherchant checkpoint, ce que j’apprend ne me renseigne sur rien comme ça, donc bon. Désolé de n’avoir aucun moyen de t’aider.
Tu as essayé de faire tourner le client vpn sous wine ?

#32

Non j’ai pas tenté encre avec wine, pour l’instant j’avais besoin que ça marche vite (donc machine virtuelle windows) et j’ai lu à côté deux trois trucs de ci de là pour voir comment je pourrait tenter de faire marcher la chose en natif.

Mais il existe plusieurs moyens de s’authentifier et autant de “technologies” et de dérivés. D’un côté on te parle de Racoon + Ike + Ipsec, de l’autre de vpnc + pam_securid.so obscur, de l’autres de openvpn et pouf ça marche… J’ai testé pour l’instant kvpnc ( que je trouve assez sympa comme interface de gestion de comptes client vpn ) avec vpnc et openvpn. J’ai presque cru avoir réussi avec openvpn mais il m’a planté une histoire de certificats qu’il avait pas.

Et bien entendu pour simplifier le tout je ne pense pas pouvoir obtenir la moindre information de la part de ma boite (35000 employés dans la boite, les gars en charge de la “sécurité” dans un environnement full MS risquent de pas être coopératifs… en plus d’être sûrement à 3000km de moi).

#33

Sans surprise le client checkpoint ne marche pas sous wine. L’installation plante au moment de créer les interfaces réseau virtuelles, logique d’un autre côté puisque wine n’a aucune accès à la config réseau ou quoi que ce soit.

Je vais donc continuer de creuser du côté d’OpenVPN plutôt. Mais là tout de suite c’est boxing days, il est temps de faire chauffer la carte de crédit :stuck_out_tongue:

#34

bonjour tout le monde,
j’aimerai savoir s’il vous plait si la configuration ennoncée dans ce sujet peut correspondre à l’architecture reseau ci-dessous

EDIT (modération): l’image qui avait été enregistrée chez casimages.com le 24/09/2009
n’est malheureusement plus accessible à ce jour

ou alors me faudrait’il configurer mes deux serveurs à la fois client et serveur?
merci

#35

En l’occurrence le schéma n’est pas très clair, si le tunnel n’est qu’une communication entre les deux serveurs debian, il te suffit d’un VPN simple, pas la peine de mettre un bridge, l’un est serveur l’autre est client.

#36

désolé pour le schéma :unamused:
en fait je voudrais réaliser un bridge entre deux réseaux et je me demande si le client est le serveur 2 de mon schéma

#37

Je précise ma pensée, un bridge signifie que l’un des serveurs est sur le réseau de l’autre, je vois ici
Un groupe G1 de machines sur un réseau R1, attaché au serveur S1
Un groupe G2 de machines sur un réseau R2, attaché au serveur S2
S1 et S2 relié par VPN bridge.

Bon cela signifie-t-il

  • S2 est intégré dans R1 (=> S1 serveur VPN, S2 client)
  • S1 est intégré dans R2 (=> S2 serveur VPN, S1 client)
  • S1 et S2 dans un réseau R3 (=> pas besoin de bridge, S1 serveur et S2 client ou l’inverse)
  • Fusion de R1 et R2 (auquel cas S1 serveur, S2 et toutes les machines de R2 clientes)
#38

Dacord, et merci de ton aide :smt006

#39

J’ai installé OpenVPN sur ma machine et je l’ai configuré en mode bridge et ca marche nickel. Merci pour l’aide sur le forum.

#40

Quelques compléments:

  1. Serveur avec juste une clef de cryptage pour connecter une machine à une autre:

serveur.conf :

secret local.key
port 1194
proto udp
dev tap
ifconfig 10.8.1.1 255.255.255.0p

client.conf

remote 192.168.1.251 1194
proto udp
dev tap
secret local.key
ifconfig 10.8.1.3 255.255.255.0
route-gateway  10.8.1.1

par exemple.

  1. Serveur non bridge avec un DHCP:

serveur.conf

port 1194
proto udp
dev tap0
ca ca.crt
cert serveur.crt
key serveur.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server 10.8.0.0 255.255.255.0
keepalive 10 120
user openvpn
group openvpn
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 1

client.conf

client
dev tap0
proto udp
remote 192.168.1.251 14142
resolv-retry infinite
nobind
user francois
group francois
persist-key
persist-tun
ca serveur.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 6
  1. Serveur avec des IPs fixes définies par les postes clients:

serveur.conf

port 1194
proto udp
dev tap
ca ca.crt
cert serveur.crt
key serveur.key
dh dh1024.pem
mode server
tls-server
ifconfig 192.168.0.6 255.255.255.0
keepalive 10 120
duplicate-cn
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 1

l’IP du serveur est 192.168.0.6
duplicate-cn permet ici à plusieurs clients de se connecter avec le même certificat.

client.conf :

client
dev tap
proto udp
remote  172.16.41.100 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca serveur.crt
cert client.crt
key client.key
ifconfig 192.168.0.200 255.255.255.0
ns-cert-type server
comp-lzo
verb 6

la machine ici a été mise avec une IP à 192.168.0.200

Attention, les machines peuvent se connecter au serveur mais pas entre elles, si on le veut il faut modifier la table de routage.

#41

Mmmm Merci Fran.b pour ces petits complements :wink: Ils sont bien sympatiques…