je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan ), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machi ne du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` T OS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 S EQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan ), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machi ne du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC=192.168.3.50 DST=192.168.3.200 LEN=60 T OS=0x00
PREC=0x00 TTL=127 ID=770 PROTO=ICMP TYPE=8 CODE=0 ID=1280 S EQ=256
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Bonjour à tous,
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du Lan ), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une machi ne du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` T OS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 S EQ%6
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Avez vous une idée de la règle a appliquer
Salut,
Tekpi a écrit :
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du La n), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une mach ine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Je suppose que eth0 et tap0 sont les ports du pont côté LAN et côté VPN
respectivement ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Salut,
Tekpi a écrit :
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du La n), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une mach ine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC=192.168.3.50 DST=192.168.3.200 LEN=60 TOS=0x00
PREC=0x00 TTL=127 ID=770 PROTO=ICMP TYPE=8 CODE=0 ID=1280 SEQ=256
Il n'y a pas de PHYSOUT= ?
J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Je suppose que eth0 et tap0 sont les ports du pont côté LAN et côté VPN
respectivement ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Salut,
Tekpi a écrit :
je viens de terminer l'installation d'un openvpn, tout se passe bien.
Voici le schéma de mon installation
Client lambda <-----> Internet <------> Routeur adsl <--------> Eth1
<-------------> Br0 <-----------> Lan
j'arrive bien à pinger le routeur adsl, eth1 et Br0.
Cependant quand j'essaie d'accéder derrière Br0 (machine du La n), ça ne
fonctionne pas. J'ai monté un script sous iptables.
Si j'ouvre tout dans mon script cela fonctionne.
Si j'applique mon script, voilà le retour pour un ping sur une mach ine du
lan à partir du client lambda :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0
--physdev-out
tap0 -j ACCEPT
et
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in tap0 -j ACCEPT
Je suppose que eth0 et tap0 sont les ports du pont côté LAN et côté VPN
respectivement ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br0
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
[Remise en l'ordre de la réponse]
Tekpi a écrit :Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
D'après mes échantillons de logs iptables avec pontage, ce type de log
est créé lorsqu'un paquet entré par le port d'un pont n'es t pas
retransmis par pontage mais routé par la pile IP. Peux-tu indiquer l es
configurations IP et tables de routage des trois machines client VPN,
serveur VPN et machine du LAN, avec "ifconfig" et "route -n" (ou "ip
addr" et "ip route" pour une version condensée) ?
[Remise en l'ordre de la réponse]
Tekpi a écrit :
Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br
OUT=br0 PHYSIN=tap0 SRC=192.168.3.50 DST=192.168.3.200 LEN=60 TOS=0x00
PREC=0x00 TTL=127 ID=770 PROTO=ICMP TYPE=8 CODE=0 ID=1280 SEQ=256
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
D'après mes échantillons de logs iptables avec pontage, ce type de log
est créé lorsqu'un paquet entré par le port d'un pont n'es t pas
retransmis par pontage mais routé par la pile IP. Peux-tu indiquer l es
configurations IP et tables de routage des trois machines client VPN,
serveur VPN et machine du LAN, avec "ifconfig" et "route -n" (ou "ip
addr" et "ip route" pour une version condensée) ?
[Remise en l'ordre de la réponse]
Tekpi a écrit :Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br
OUT=br0 PHYSIN=tap0 SRC2.168.3.50 DST2.168.3.200 LEN` TOS=0x00
PREC=0x00 TTL7 IDw0 PROTO=ICMP TYPE=8 CODE=0 ID80 SEQ%6
Il n'y a pas de PHYSOUT= ?
1/Pas de physout
D'après mes échantillons de logs iptables avec pontage, ce type de log
est créé lorsqu'un paquet entré par le port d'un pont n'es t pas
retransmis par pontage mais routé par la pile IP. Peux-tu indiquer l es
configurations IP et tables de routage des trois machines client VPN,
serveur VPN et machine du LAN, avec "ifconfig" et "route -n" (ou "ip
addr" et "ip route" pour une version condensée) ?
Je n'ai pas accès au serveur du lan.
voici la route du linux (openvpn) :
192.168.3.1 dev eth1 scope link #Ici j'ai forcé la route pour accéder au
routeur, si j'enlève cela, le linux n'a plus le net car il se retourne vers
l'interface lan pour trouver l'ip du routeur
192.168.3.0/24 dev eth0 scope link
192.168.3.0/24 dev br0 scope link
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.2
default via 192.168.3.1 dev br0
default via 192.168.3.1 dev eth1
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
Je n'ai pas accès au serveur du lan.
voici la route du linux (openvpn) :
192.168.3.1 dev eth1 scope link #Ici j'ai forcé la route pour accéder au
routeur, si j'enlève cela, le linux n'a plus le net car il se retourne vers
l'interface lan pour trouver l'ip du routeur
192.168.3.0/24 dev eth0 scope link
192.168.3.0/24 dev br0 scope link
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.2
default via 192.168.3.1 dev br0
default via 192.168.3.1 dev eth1
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
Je n'ai pas accès au serveur du lan.
voici la route du linux (openvpn) :
192.168.3.1 dev eth1 scope link #Ici j'ai forcé la route pour accéder au
routeur, si j'enlève cela, le linux n'a plus le net car il se retourne vers
l'interface lan pour trouver l'ip du routeur
192.168.3.0/24 dev eth0 scope link
192.168.3.0/24 dev br0 scope link
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.2
default via 192.168.3.1 dev br0
default via 192.168.3.1 dev eth1
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
>Tant pis, on devrait pouvoir se débrouiller sans. Par contre j'aurais
aimé avoir les sorties de ifconfig|ipconfig, pour ne pas avoir besoin de
jouer aux devinettes concernant les adresses et masques. Tant pis
aussi... (bis repetita)
Ah, forcément si tu configures le même sous-réseau IP 192.1 68.3.0/24 sur
deux interfaces reliées à des réseaux différents, à §a va beaucoup moins
bien marcher comme dirait l'autre. Après, pas étonnant qu'il fai lle des
rustines pour faire à peu près marcher une configuration boiteus e.
Je suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes pa r
défaut, contradictoires pour la plupart.
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennen t.
Au final, la table de routage devrait ressembler à ceci :
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.4.0/24 dev eth1 proto kernel scope link src 192.168.4.2
default via 192.168.4.1 dev eth1
J'ai renuméroté le sous-réseau eth1-routeur ADSL en 192.168 .4.0/4,
l'adresse de eth1 en 192.168.4.2 et l'adresse du routeur en 192.168.4.1.
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. int erface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-rés eau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là . Poussée par le serveur VPN ? En tout cas je pen se que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une p riorité
supérieure) à la route directe juste au dessus.
>Tant pis, on devrait pouvoir se débrouiller sans. Par contre j'aurais
aimé avoir les sorties de ifconfig|ipconfig, pour ne pas avoir besoin de
jouer aux devinettes concernant les adresses et masques. Tant pis
aussi... (bis repetita)
Ah, forcément si tu configures le même sous-réseau IP 192.1 68.3.0/24 sur
deux interfaces reliées à des réseaux différents, à §a va beaucoup moins
bien marcher comme dirait l'autre. Après, pas étonnant qu'il fai lle des
rustines pour faire à peu près marcher une configuration boiteus e.
Je suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes pa r
défaut, contradictoires pour la plupart.
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennen t.
Au final, la table de routage devrait ressembler à ceci :
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.4.0/24 dev eth1 proto kernel scope link src 192.168.4.2
default via 192.168.4.1 dev eth1
J'ai renuméroté le sous-réseau eth1-routeur ADSL en 192.168 .4.0/4,
l'adresse de eth1 en 192.168.4.2 et l'adresse du routeur en 192.168.4.1.
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. int erface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-rés eau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là . Poussée par le serveur VPN ? En tout cas je pen se que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une p riorité
supérieure) à la route directe juste au dessus.
>Tant pis, on devrait pouvoir se débrouiller sans. Par contre j'aurais
aimé avoir les sorties de ifconfig|ipconfig, pour ne pas avoir besoin de
jouer aux devinettes concernant les adresses et masques. Tant pis
aussi... (bis repetita)
Ah, forcément si tu configures le même sous-réseau IP 192.1 68.3.0/24 sur
deux interfaces reliées à des réseaux différents, à §a va beaucoup moins
bien marcher comme dirait l'autre. Après, pas étonnant qu'il fai lle des
rustines pour faire à peu près marcher une configuration boiteus e.
Je suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes pa r
défaut, contradictoires pour la plupart.
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennen t.
Au final, la table de routage devrait ressembler à ceci :
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
192.168.4.0/24 dev eth1 proto kernel scope link src 192.168.4.2
default via 192.168.4.1 dev eth1
J'ai renuméroté le sous-réseau eth1-routeur ADSL en 192.168 .4.0/4,
l'adresse de eth1 en 192.168.4.2 et l'adresse du routeur en 192.168.4.1.
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. int erface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-rés eau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là . Poussée par le serveur VPN ? En tout cas je pen se que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une p riorité
supérieure) à la route directe juste au dessus.
ipconfig : Carte Ethernet Connexion au réseau local:
ifconfig :
Ah, forcément si tu configures le même sous-réseau IP 192.168.3.0/24 sur
deux interfaces reliées à des réseaux différents, ça va beaucoup moins
bien marcher comme dirait l'autre.
Figures toi que j'ai demandé conseil sur ce forum en développant ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait faire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
être sur le même réseau?
Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1
192.168.1.0/24.
En gros, le schéma :
Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennent.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me parait
bizarre, c'est que cela fonctionne si j'ouvre complètement mon script
iptables...
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-réseau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là. Poussée par le serveur VPN ? En tout cas je pense que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une priorité
supérieure) à la route directe juste au dessus.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda.
J'ai supprimé cette option car je pensais qu'elle pouvait être la source du
pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lambda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
ipconfig : Carte Ethernet Connexion au réseau local:
ifconfig :
Ah, forcément si tu configures le même sous-réseau IP 192.168.3.0/24 sur
deux interfaces reliées à des réseaux différents, ça va beaucoup moins
bien marcher comme dirait l'autre.
Figures toi que j'ai demandé conseil sur ce forum en développant ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait faire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
être sur le même réseau?
Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1
192.168.1.0/24.
En gros, le schéma :
Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennent.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me parait
bizarre, c'est que cela fonctionne si j'ouvre complètement mon script
iptables...
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-réseau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là. Poussée par le serveur VPN ? En tout cas je pense que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une priorité
supérieure) à la route directe juste au dessus.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda.
J'ai supprimé cette option car je pensais qu'elle pouvait être la source du
pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lambda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
ipconfig : Carte Ethernet Connexion au réseau local:
ifconfig :
Ah, forcément si tu configures le même sous-réseau IP 192.168.3.0/24 sur
deux interfaces reliées à des réseaux différents, ça va beaucoup moins
bien marcher comme dirait l'autre.
Figures toi que j'ai demandé conseil sur ce forum en développant ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait faire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
être sur le même réseau?
Car actuellement, j'ai configuré mon eth0 en 192.168.5.0/24 et eth1
192.168.1.0/24.
En gros, le schéma :
Client winxp <------> VPN <-----------> eth0 linux eth1 <------------> Lan
Primo, configurer deux sous-réseaux distincts pour le segment
eth1-routeur ADSL et pour le segment br0-LAN-VPN.
Secundo, eth0 fait partie du pont et donc ne doit être associé à aucune
adresse IP ni route.
Tertio, virer les routes redondantes, en cherchant d'où elles viennent.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me parait
bizarre, c'est que cela fonctionne si j'ouvre complètement mon script
iptables...
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-réseau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN. Je serais curieux de savoir comment elle est
arrivée là. Poussée par le serveur VPN ? En tout cas je pense que c'est
elle qui provoque le routage des paquets au lieu du pontage : au lieu
d'être envoyés directement au LAN, ils sont envoyés à l'adresse de la
passerelle car cette route a une métrique inférieure (donc une priorité
supérieure) à la route directe juste au dessus.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda.
J'ai supprimé cette option car je pensais qu'elle pouvait être la source du
pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lambda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
Tekpi a écrit :
ipconfig : Carte Ethernet Connexion au réseau local:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.10.69
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.10.1
Carte Ethernet Connexion au réseau local 2:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.3.50
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . :
ifconfig :
br0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet addr:192.168.3.254 Bcast:192.168.3.255 Mask:255.255.255. 0
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:1B:11:63:4F:CF
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::21b:11ff:fe63:4fcf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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
tap0 Link encap:Ethernet HWaddr 9A:FA:92:99:45:CD
inet6 addr: fe80::98fa:92ff:fe99:45cd/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1Ah, forcément si tu configures le même sous-réseau IP 192. 168.3.0/24 sur
deux interfaces
Figures toi que j'ai demandé conseil sur ce forum en développan t ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait f aire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
En même temps j'ai peut être mal compris lolJe suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
oui.Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes p ar
défaut, contradictoires pour la plupart.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me
parait bizarre, c'est que cela fonctionne si j'ouvre complètement mo n
script iptables...Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. in terface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-ré seau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda .
J'ai supprimé cette option car je pensais qu'elle pouvait être la source
du pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lam bda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
Merci pour ton aide.
Tekpi a écrit :
ipconfig : Carte Ethernet Connexion au réseau local:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.10.69
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.10.1
Carte Ethernet Connexion au réseau local 2:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.3.50
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . :
ifconfig :
br0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet addr:192.168.3.254 Bcast:192.168.3.255 Mask:255.255.255. 0
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:1B:11:63:4F:CF
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::21b:11ff:fe63:4fcf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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
tap0 Link encap:Ethernet HWaddr 9A:FA:92:99:45:CD
inet6 addr: fe80::98fa:92ff:fe99:45cd/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Ah, forcément si tu configures le même sous-réseau IP 192. 168.3.0/24 sur
deux interfaces
Figures toi que j'ai demandé conseil sur ce forum en développan t ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait f aire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
En même temps j'ai peut être mal compris lol
Je suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
oui.
Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes p ar
défaut, contradictoires pour la plupart.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me
parait bizarre, c'est que cela fonctionne si j'ouvre complètement mo n
script iptables...
Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. in terface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1
Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-ré seau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda .
J'ai supprimé cette option car je pensais qu'elle pouvait être la source
du pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lam bda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
Merci pour ton aide.
Tekpi a écrit :
ipconfig : Carte Ethernet Connexion au réseau local:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.10.69
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.10.1
Carte Ethernet Connexion au réseau local 2:
Suffixe DNS propre à la connexion :
Adresse IP. . . . . . . . . . . . : 192.168.3.50
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . :
ifconfig :
br0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet addr:192.168.3.254 Bcast:192.168.3.255 Mask:255.255.255. 0
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0 Link encap:Ethernet HWaddr 00:19:21:5C:A5:CA
inet6 addr: fe80::219:21ff:fe5c:a5ca/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:1B:11:63:4F:CF
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::21b:11ff:fe63:4fcf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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
tap0 Link encap:Ethernet HWaddr 9A:FA:92:99:45:CD
inet6 addr: fe80::98fa:92ff:fe99:45cd/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1Ah, forcément si tu configures le même sous-réseau IP 192. 168.3.0/24 sur
deux interfaces
Figures toi que j'ai demandé conseil sur ce forum en développan t ma
topologie réseau et mes besoins, on m'a répondu qu'il fallait f aire du vpn
bridgé et donc que les interfaces lan et wan soient les mêmes.
En même temps j'ai peut être mal compris lolJe suppose que 192.168.3.2 est l'adresse de eth1, 192.168.3.254 celle de
br0 et 192.168.3.1 celle du routeur ADSL.
oui.Quel bazar là -dedans !
Pas moins de 4 routes pour le même sous-réseau et deux routes p ar
défaut, contradictoires pour la plupart.
Cela signifie que je dois reconfigurer mon script iptables. Ce qui me
parait bizarre, c'est que cela fonctionne si j'ouvre complètement mo n
script iptables...Voici la route du poste lambda (avec connexion vpn lancée) :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. in terface
Métrique
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50
30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50
1Je n'ai gardé que les routes non locales et non broadcast liées au VPN,
pour la lisibilité. Il y a un intrus : la route vers le sous-ré seau du
LAN 192.168.3.0/24 ayant comme passerelle 192.168.3.2, adresse
appartenant au serveur VPN.
Oui, c'est bien le openvpn.conf qui force cette route sur le poste lambda .
J'ai supprimé cette option car je pensais qu'elle pouvait être la source
du pb, sans résultat.
Ce qui est franchement étrange, c'est que je peux, via mon poste lam bda,
faire un ping ou même faire du ssh sur la pate lan du linux...
Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?
Merci pour ton aide.