Configurer OpenVPN en mode bridge

DJ Raging-Bull · Le 08/06/2014, à 09:55

Bonjour,

J'avais déjà fais un sujet là dessus dans la partie serveur, mais là j'ai un problème qui concerne plus la partie réseau.
Je dispose d'une Box de Numéricâble avec connexion 200 Mbp/s en DL et 20 Mbp/s en UL.
Cette box est la passerelle par défaut de mon réseau et son adresse IP est: 192.168.0.1
Je dispose également d'un HTPC décrit dans ma signature et son adresse IP est: 192.168.0.19
Et d'après ce que je vois en faisant "ifconfig" l'IP broadcast est: 192.168.0.255
Mais c'est noté nulle part sur la Box, ça n'apparaît pas sous Windows, juste sous Ubuntu quand je fais un "ifconfig" ou quand je vais dans le gestionnaire réseau.

Je souhaite mettre en place un serveur OpenVPN en mode bridge qui permet aux utilisateurs de faire partie du réseau local du serveur et de se voir entre eux. Notamment pour jouer sur Steam en streaming en dehors de chez moi ou pour jouer à des jeux vidéo en mode "réseau local" avec des amis ou autres, enfin bref peu importe, le principal c'est qu'il doit être en bridge.

Mon problème est que dès que je lance le scripte qui créer le bridge ou quand je configure ça dans /etc/network/interfaces et que je redémarre le réseau, le serveur n'a plus accès à internet et n'est plus accessible depuis internet.
Je ne peux plus non plus accéder à la Box depuis le serveur et la Box ne m'indique pas que le serveur est connecté au LAN.
POURTANT le serveur est toujours accessible depuis le LAN avec son adresse 192.168.0.19 ...
A la seconde ou je désactive le bridge tout redevient comme avant.

Une idée ? Parce que là je me triture les méninges depuis 2 jours et ça commence doucement à me décourager.

Edit: J'avais activé la réservation d'IP sur le LAN en fonction de l'adresse MAC du serveur, je l'ai viré pour être sur que le routeur ne lui refuse pas la connexion en ne reconnaissant pas l'adresse MAC du périphérique réseau virtuel, mais ça n'arrange pas mon problème. On dirait que le serveur ne trouve plus la passerelle par défaut une fois le bridge en place. Comment y remédier ?

Dernière modification par DJ Raging-Bull (Le 08/06/2014, à 19:09)

DJ Raging-Bull · Le 08/06/2014, à 20:55

Bon, dernière nouvelle: j'ai réussis à faire en sorte qu'il prenne en compte la passerelle par défaut via le fichier /etc/network/interfaces mais toujours aucune connexion vers ou venant d'internet. Uniquement le réseau local.
De plus, je ne sais pour quelle raison br0 clone maintenant l'adresse MAC de eth0 ...

compte supprimé · Le 08/06/2014, à 23:21

Hello, tu es sur le bon forum, regarde les titres sur les deux premières pages de ce forum, appelé ici "Accès Internet et réseaux". Il y a tout un tas de bug avec la version 14.04 lts et openVPN. Je suis presque sûr que tu ne te trompes pas dans ta configuration (voir ici si tu ne connais pas la page, mais j'en doute... : http://openvpn.net/index.php/open-sourc … dging.html ). Je pense que tu aurais plus de chance avec une 12.04.4 LTS (avis bien personnel). Et tu vas te rendre compte qu'en testant avec ta 12.0.4.4 LTS, et en ayant procédé exactement de la même façon qu'avec la 14.04, que cela fonctionne sans problème...

Bonne chance Jim.

DJ Raging-Bull · Le 09/06/2014, à 13:37

Bon, j'ai réussi à mettre en place un bridge qui fonctionne avec ce tutoriel.

Autre soucis:
Mes amis arrivent à se connecter sur mon serveur OpenVPN mais ça leur donne un "réseau non identifié" sous Windows et ils ne peuvent pas se ping entre eux ni accéder à mon réseau locale.
J'ai mis comme IP range: 192.168.0.30 -> 192.168.0.50.
LaBox de Numéricâble a un serveur DHCP qui alloue de 192.168.0.10 -> 192.168.0.29.

Je ne comprend pas trop comment configurer le tout pour faire en sorte que chaque client se voient les uns, les autres (option client-to-client déjà activé) et voit mon LAN comme si il était branché à ma Box.

Dernière modification par DJ Raging-Bull (Le 09/06/2014, à 13:37)

DJ Raging-Bull · Le 14/06/2014, à 12:11

Un petit up, on ne sait jamais.

Sat Jun 14 17:51:55 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jun  5 2014
Sat Jun 14 17:51:55 2014 library versions: OpenSSL 1.0.1h 5 Jun 2014, LZO 2.05
Sat Jun 14 17:51:55 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Jun 14 17:51:59 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Jun 14 17:51:59 2014 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sat Jun 14 17:51:59 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 14 17:51:59 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 14 17:51:59 2014 UDPv4 link local: [undef]
Sat Jun 14 17:51:59 2014 UDPv4 link remote: [AF_INET]89.3.54.103:1194
Sat Jun 14 17:51:59 2014 VERIFY OK: depth=1, C=FR, ST=Nord, L=Lille, O=Raging-Network, emailAddress=*****.*****@gmail.com
Sat Jun 14 17:51:59 2014 VERIFY OK: depth=0, C=FR, ST=Nord, L=Lille, O=Raging-Network, OU=Office, CN=raging_server_vpn, emailAddress=*******.******@gmail.com
Sat Jun 14 17:51:59 2014 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1590', remote='link-mtu 1589'
Sat Jun 14 17:51:59 2014 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Sat Jun 14 17:51:59 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Jun 14 17:51:59 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 14 17:51:59 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Jun 14 17:51:59 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 14 17:51:59 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Jun 14 17:51:59 2014 [raging_server_vpn] Peer Connection Initiated with [AF_INET]89.3.54.103:1194
Sat Jun 14 17:52:01 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jun 14 17:52:01 2014 open_tun, tt->ipv6=0
Sat Jun 14 17:52:01 2014 TAP-WIN32 device [Connexion au réseau local 3] opened: \\.\Global\{628D69CD-B2F7-44EA-AFD3-57AD02C37EA1}.tap
Sat Jun 14 17:52:01 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.30/255.255.255.0 on interface {628D69CD-B2F7-44EA-AFD3-57AD02C37EA1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Sat Jun 14 17:52:01 2014 Successful ARP Flush on interface [27] {628D69CD-B2F7-44EA-AFD3-57AD02C37EA1}
Sat Jun 14 17:52:06 2014 Initialization Sequence Completed

Je met le log de connexion au cas ou ça peut aider.

Dernière modification par DJ Raging-Bull (Le 14/06/2014, à 17:54)

kleer · Le 16/06/2014, à 03:07

Salut

Je vais t'aider un peu :
Chez moi, j'ai ça coté serveur :

port 1194
proto udp
dev tap1
ca ./keys/server_bridging_internet/ca.crt
cert ./keys/server_bridging_internet/vpn_srv.crt
key ./keys/server_bridging_internet/vpn_srv.key # This file should be kept secret
dh ./keys/server_bridging_internet/dh1024.pem
server-bridge 192.168.50.0 255.255.255.0 192.168.50.30 192.168.50.60
server-bridge
keepalive 10 120
tls-auth ./keys/server_bridging_internet/ta.key 0 # This file is secret
cipher DES-EDE3-CBC # Triple-DES
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status ./log/server_bridging_internet/openvpn-status.log
log-append ./log/server_bridging_internet/openvpn.log
verb 3

Coté client :

client
dev tap0
proto udp
remote <<ton host>> 1194
resolv-retry infinite
nobind
# Downgrade privileges after initialization (non-Windows only)
; Si le client est sur Windows, laisser commenté,
; Sur Linux, décommenter
;user nobody
;group nobody
persist-key
persist-tun
ca client_bridging_internet/ca.crt
cert client_bridging_internet/key.crt
key client_bridging_internet/key.key
ns-cert-type server
tls-auth client_bridging_internet/ta.key 1
cipher DES-EDE3-CBC
comp-lzo
verb 3

Tu parlais plus haut de client-to-client
Elle n'a pas besoin d'être activée.
Cette directive, si elle est activée fait que la communication entre clients est assurée dans le processus openvpn.
Si elle est désactivée, le trafic des client est exposé au système d'exploitation

Attention, un point important :
Il ne faut pas que tes amis aient leur réseau chez eux identiques au tien.
Tu est en 192.168.0.0/24, il ne faut pas que ce soit pareil chez eux
Pourquoi ?
Parce qu'en se connectant ils auront leur carte réseau physique et leur carte virtuelle openvpn dans le même réseau.
Ca fait des conflits dans la table de routage
Demande leur de changer d'adresse réseau, ou fait le toi.

Dans la config serveur que je t'ai donné :

server-bridge 192.168.50.0 255.255.255.0 192.168.50.30 192.168.50.60

Mon serveur VPN a une adresse du réseau 192.168.50.0/24. En se connectant, les clients auront des adresses
dans ce réseau de 192.168.50.30 à 192.168.50.60 (Adapte à ton cas)

L'ip_forward n'a pas besoin d'être activé dans le cas d'un vpn bridgé. Laisse le à 0

Assure toi que les bonnes interfaces se trouvent bien dans le bridge :

serveur:/etc/openvpn# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00138f7df70d no eth0
tap1

puis

ifconfig eth0 up
ifconfig tap1 up
ifconfig br0 up

Maintenant, le serveur de jeux devrait être joignable pour les parties en LAN

S'il reste des warnings dans les log de connexion vpn, essaye de les corriger

Une dernière chose importante :
En leur donnant un accès VPN, ils vont pouvoir se servir de ta connexion Internet.
Pour éviter ça, sur le serveur VPN :

iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A FORWARD -i br0 -s <ton réseau local / masque> -d <ton réseau local / masque> -j ACCEPT

Ca autorise uniquement les clients à se joindre entre eux

Pour annuler :

iptables -P FORWARD ACCEPT
iptables -F

A+

DJ Raging-Bull · Le 18/06/2014, à 15:31

Merci de ta réponse.

Un ami m'a conseillé 2 ou 3 petites choses, on a fait des tests ensemble et il arrivait à voir mes partages réseau, ma box, on pouvait jouer ensemble en LAN et se ping sans problème à une moyenne de 40 ms donc apriori pas de soucis.
Sauf que chez lui le réseau est considéré comme "non identifié" et la passerelle par défaut (192.168.0.1) n'est pas configurée automatiquement bien que ça ne change rien au niveau de ce qu'il peut faire sur le LAN.

En l'entrant manuellement dans l'interface réseau de Windows le réseau est reconnu et ça ne change rien pour le reste.

Ce que je trouve assez étonnant dans cette histoire est que:
1. Sa connexion réseau est non identifié et n'a pas de passerelle par défaut mais accède quand même à mon LAN sans aucune difficulté
2. Le faite d'ajouter manuellement la passerelle dans les options de l'interface réseau Windows nous donne un réseau bien identifié et ne change rien à l'accès au LAN
3. J'ai l'impression que ce serveur OpenVPN est très instable. A la moindre modification d'option côté fichier de configuration du serveur, scripte pour le bridge ou côté fichier de configuration du client, plus rien ne fonctionne. Entendez par là comme symptôme: le client se connecte à OpenVPN et obtient bien une adresse IP mais ne peut ping personne et n'a accès à aucune ressource du LAN.

Voici le fichier de configuration du serveur:

port 1194
proto udp
dev tap1
ca keys/djragingbull/ca.crt
cert keys/djragingbull/raging_server_vpn.crt
key keys/djragingbull/raging_server_vpn.key
dh keys/djragingbull/dh2048.pem
server-bridge 192.168.0.1 255.255.255.0 192.168.0.30 192.168.0.50 #@@ tap0 eth0
crl-verify keys/djragingbull/crl.pem
tls-auth servers/Raging_Server_VPN/ta.key 0
cipher AES-256-CBC
user nobody
group nogroup
status servers/Raging_Server_VPN/logs/openvpn-status.log
log-append servers/Raging_Server_VPN/logs/openvpn.log
verb 5
mute 20
max-clients 20
management 127.0.0.1 10001
keepalive 10 120
client-config-dir /etc/openvpn/servers/Raging_Server_VPN/ccd
tls-server
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "dhcp-option DNS 82.2.0.1"
push "dhcp-option DNS 82.2.0.2"

Voici le scripte pour activer le bridge:

#!/bin/bash
 
# On créer un tunnel persistant en mode TAP.
openvpn --mktun --dev tap0
 
# On créer une nouvelle interface de type "bridge".
brctl addbr br0

# On ajoute l’interface du réseau DMZ et l’interface virtuelle TAP dans le bridge.
brctl addif br0 tap0
brctl addif br0 eth0
 
# On configure les interfaces en mode promiscuous (elles écoutent tout,
# mais n’ont pas d’adresses IP)
ifconfig eth0 0.0.0.0 promisc up
ifconfig tap0 0.0.0.0 promisc up
 
# On configure l’IP de l’interface "bridge" avec l’ancienne adresse de eth0.
ifconfig br0 hw ether d8:50:e6:ba:1d:b5
ifconfig br0 192.168.0.19 netmask 255.255.255.0 broadcast 192.168.0.255 up
 
# On ajoute les routes pour atteindre les réseaux de la zone local.
route add -net 192.168.0.0 netmask 255.255.255.0
dhclient br0

Et voici le fichier de configuration du client:

client
proto udp
dev tap
ca ca.crt
dh dh2048.pem
cert kaizeru.crt
key kaizeru.key
remote xxxxxx-xxxxxxx.xxxx.xx 1194
tls-auth ta.key 1
cipher AES-256-CBC
user nobody
group nogroup
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind
push "route-gateway 192.168.0.1"

Pour rappel:
Passerelle par défaut et serveur DHCP (LaBox de Numéricâble): 192.168.0.1
L'adresse IP du serveur: 192.168.0.19
L'adresse IP broadcast: 192.168.0.255
L'adresse IP des serveurs DNS: 82.2.0.1 et 82.2.0.2

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/06/2014, à 09:55

Configurer OpenVPN en mode bridge

#2 Le 08/06/2014, à 20:55

Re : Configurer OpenVPN en mode bridge

#3 Le 08/06/2014, à 23:21

Re : Configurer OpenVPN en mode bridge

#4 Le 09/06/2014, à 13:37

Re : Configurer OpenVPN en mode bridge

#5 Le 14/06/2014, à 12:11

Re : Configurer OpenVPN en mode bridge

#6 Le 16/06/2014, à 03:07

Re : Configurer OpenVPN en mode bridge

#7 Le 18/06/2014, à 15:31

Re : Configurer OpenVPN en mode bridge

Pied de page des forums