iptables et openvpn

Le
Tekpi
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 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

J'ai appliqué cette règle, sans succès :
iptables -A FORWARD -i br0 -o br0 -m physdev --physdev-in eth0 --physdev-ou=
t
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?

merci pour votre aide.

--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4=
895724.html#a14021257
Sent from the debian-user-french mailing list archive at Nabble.com.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #9740241
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 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



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
Daniel Huhardeaux
Le #9740201
Tekpi a écrit :
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


Voila les règles qui nous ont permis de nous en sortir

# Masquerade IntraNet to VPN with our Internet IP.
$IPTABLES -t nat -A POSTROUTING -s $VPN_NET -o $INTERNAL_DEVICE -j
MASQUERADE
# Masquerade IntraNet to VPN with our Internet IP.
$IPTABLES -t nat -A POSTROUTING -o $VPN_DEVICE -j
MASQUERADE


--
Daniel


--
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
Tekpi
Le #9740191
Bonjour,

merci pour ta réponse.

Est-ce que cela peut rentrer en conflit avec des règles nat que j'ai c réé?

Pour simplifier, derrière le firewall, j'ai un serveur web, le firewal l
redirige toutes les requêtes du port 80 et 443 sur ce serveur.

Merci



Tekpi a écrit :
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


Voila les règles qui nous ont permis de nous en sortir

# Masquerade IntraNet to VPN with our Internet IP.
$IPTABLES -t nat -A POSTROUTING -s $VPN_NET -o $INTERNAL_DEVICE -j
MASQUERADE
# Masquerade IntraNet to VPN with our Internet IP.
$IPTABLES -t nat -A POSTROUTING -o $VPN_DEVICE -j
MASQUERADE


--
Daniel

--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4 895724.html#a14022960
Sent from the debian-user-french mailing list archive at Nabble.com.
Tekpi
Le #9740181
merci pour ta réponse.

1/Pas de physout
2/ br0, eth0 -> Lan
tap0 -> vpn

merci



Pascal Hambourg wrote:

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







--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4 895724.html#a14022962
Sent from the debian-user-french mailing list archive at Nabble.com.
Pascal Hambourg
Le #9740151
[Remise en l'ordre de la réponse]

Tekpi a écrit :

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



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'est pas
retransmis par pontage mais routé par la pile IP. Peux-tu indiquer les
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) ?


--
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
Tekpi
Le #9740081
Bonsoir et merci pour ta réponse.

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. inter face
Métrique
0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.69 2
0
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.3.0 255.255.255.0 192.168.3.50 192.168.3.50 3
0
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.50 1
192.168.3.50 255.255.255.255 127.0.0.1 127.0.0.1 3
0
192.168.3.255 255.255.255.255 192.168.3.50 192.168.3.50 3
0
192.168.10.0 255.255.255.0 192.168.10.69 192.168.10.69 2
0
192.168.10.69 255.255.255.255 127.0.0.1 127.0.0.1 2
0
192.168.10.255 255.255.255.255 192.168.10.69 192.168.10.69 2
0
224.0.0.0 240.0.0.0 192.168.3.50 192.168.3.50 3
0
224.0.0.0 240.0.0.0 192.168.10.69 192.168.10.69 2
0
255.255.255.255 255.255.255.255 192.168.3.50 192.168.3.50 1
255.255.255.255 255.255.255.255 192.168.10.69 192.168.10.69 1
Passerelle par défaut : 192.168.10.1
========================= ========================= =========================
Itinéraires persistants :
Aucun

Pascal Hambourg wrote:

[Remise en l'ordre de la réponse]

Tekpi a écrit :

Nov 29 09:19:59 ubuntu kernel: [53863.278373] [IPTABLES DROP] : IN=br








0
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) ?






--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4 895724.html#a14030654
Sent from the debian-user-french mailing list archive at Nabble.com.
Pascal Hambourg
Le #9740051
Tekpi a écrit :

Je n'ai pas accès au serveur du lan.



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)

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



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. Après, pas étonnant qu'il faille des
rustines pour faire à peu près marcher une configuration boiteuse.

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



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 par
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 viennent.

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. 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.


--
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
Tekpi
Le #9739991
>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)



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
RX packets:185826 errors:0 dropped:0 overruns:0 frame:0
TX packets:79746 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:198779227 (189.5 MiB) TX bytes:5208874 (4.9 MiB)

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
RX packets:202292 errors:0 dropped:0 overruns:0 frame:0
TX packets:79749 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:199542242 (190.2 MiB) TX bytes:5208936 (4.9 MiB)
Interrupt:19

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
RX packets:80975 errors:0 dropped:0 overruns:0 frame:0
TX packets:146856 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5766455 (5.4 MiB) TX bytes:196969433 (187.8 MiB)
Interrupt:21 Base address:0xec00

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
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

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
RX packets:80 errors:0 dropped:0 overruns:0 frame:0
TX packets:45865 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:10709 (10.4 KiB) TX bytes:3252694 (3.1 MiB)

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.



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 fai re 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.



Bien deviné.

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.



Cela signifie que je dois reconfigurer mon script iptables. Ce qui me parai t
bizarre, c'est que cela fonctionne si j'ouvre complètement mon script
iptables...

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.



Nickel.

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.



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 lambd a,
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.
--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4 895724.html#a14042387
Sent from the debian-user-french mailing list archive at Nabble.com.
Pascal Hambourg
Le #9739951
Tekpi a écrit :

ipconfig : Carte Ethernet Connexion au réseau local:


[...]
ifconfig :


[...]

Merci, ça confirme mes déductions. Rien à signaler à part br0 et eth1
dans le même sous-réseau, comme je l'ai déjà dit.

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.



J'avais déjà oubliée cette discussion...
Sauf erreur, personne ici ne t'a dit qu'il fallait faire du VPN ponté,
c'est toi qui l'as choisi, et encore moins que les interfaces WAN et LAN
devaient être "les mêmes".

J'avais répondu ceci :
====================================================================== > l'interface eth0 et eth1 de mon serveur linux doivent-elles impérativement
ê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



eth0, c'est quoi ? L'interface WAN vers internet ?

Si pontage : l'interface LAN, eth1, doit être pontée avec l'interface
VPN, tapX. Elles sont de fait sur le même réseau, comme les ports d'un
switch. Elles deviennent les ports d'un switch virtuel constitué par le
pont. D'autre part dans la configuration de la machine l'interface pont
(br0) doit remplacer eth1. Ce n'est plus eth1 mais br0 qui a la
configuration IP, les routes associées, qui est utilisée par le serveur
DHCP le cas échéant, etc. Au niveau réseau, eth1 et tapX seront aussi
invisibles que les ports d'un switch.
======================================================================
Il n'était pas fait mention de l'interface WAN dans ma réponse. On peut
éventuellement la mettre dans le pont (et supprimer la fonction routeur
du serveur), mais en aucun cas dans le même sous-réseau.

Explication :
si l'interface WAN est dans le pont, elle n'est plus une interface
individuelle et n'a plus d'adresse IP ni de sous-réseau ; le serveur se
comporte come un switch à 3 ports WAN-LAN-VPN, il n'y a plus qu'un seul
réseau.
Si l'interface WAN n'est pas dans le pont, elle a son propre sous-réseau
IP distinct de celui du pont-LAN ; le serveur se comporte comme un
switch entre LAN et VPN et comme un routeur entre WAN et (LAN+VPN).

En bref, seules les interfaces individuelles et les ponts ont des
adresses IP et des sous-réseaux (distincts). Les interfaces pontées
disparaissent.

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...



S'il n'est pas trop long ou confidentiel tu peux le publier, qu'on jette
un oeil.

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.



Et si tu supprimes les options physdev des règles iptables que tu avais
indiquées, pour voir ?

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...



Rien d'étrange là-dedans. Tu n'accèdes pas à la patte LAN du serveur
mais à l'adresse de sa patte LAN, sur sa patte VPN. La nuance est de
taille. C'est géré dans les chaînes iptables INPUT et OUTPUT, et non
dans la chaîne FORWARD.

Pourquoi m'aurait-on dit de mettre toutes les interfaces du linux dans le
même sous réseau pour bridgé le vpn?



Je ne sais pas pourquoi ni qui t'a dit ça, mais ce n'était pas ici dans
la discussion "VPN client Windows -> Serveur Debian".

Autant il peut être intéressant de ponter le VPN avec le LAN
(broadcasts, protocoles non IP) autant ça n'a guère d'intérêt de ponter
le LAN (ou le VPN) avec le WAN. Ce n'est d'ailleurs pas toujours
possible, par exemple lorsque le WAN n'est pas un réseau ethernet mais
un lien PPP.


--
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
Tekpi
Le #9739931
Pascal Hambourg wrote:

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.




--
View this message in context: http://www.nabble.com/iptables-et-openvpn-tf4 895724.html#a14042561
Sent from the debian-user-french mailing list archive at Nabble.com.
Publicité
Poster une réponse
Anonyme