Pb de routage entre deux sites via openvpn
Le
Yann Cohen
Bonjour,
je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn.
Chaque coté du tunnel est un serveur debian (old-stable et jessie).
Le serveur (firewall) est coté old-stable, le client coté jessie.
Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
192.168.1.0/24
Le vpn est dans le plan d'@ 192.168.100.0/24
Le client (sky) dessert le réseau 192.168.29.0/24.
la table de routage coté serveur est la suivante :
root@firewall:/etc/openvpn# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.100.2 0.0.0.0 255.255.255.255 UH 0 0 0
tun0
192.168.100.0 192.168.100.2 255.255.255.0 UG 0 0 0
tun0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0
eth2
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
192.168.29.0 192.168.100.2 255.255.255.0 UG 0 0 0
tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
eth1
la table de routage coté client est la suivante :
root@sky:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fenêtre irtt
Iface
0.0.0.0 192.168.29.1 0.0.0.0 UG 0 0 0
br0
192.168.1.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.3.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.4.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.29.0 0.0.0.0 255.255.255.0 U 0 0 0
br0
192.168.100.1 192.168.100.21 255.255.255.255 UGH 0 0 0
tun0
192.168.100.21 0.0.0.0 255.255.255.255 UH 0 0 0
tun0
Les routes viennent de la configuration openvpn via les directives :
push route pour .4, .3, .1
route et iroute pour .29
via fwbuilder la table de routage est configurée de chaque coté pour ne
rien bloquer (enfin c'est ce que je crois).
De chaque coté j'ai mis en place un tshark sur l'interface tun0 et un
sur l'interface eth0 ou br0. Objectif suivre les paquets "icmp".
Les pings et les pongs depuis le client (sky) vers l'adresse du serveur
(firewall) en .3 passent.
Les pings depuis firewall vers sky sur l'adresse en .29 ne sont pas
envoyés sur tun0 de firewall.
Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.
Je sèche sur ce problème depuis un bon paquets d'heures.
Je suppose que le problème est coté serveur (firewall) mais je ne sais
plus où chercher.
Je suis donc preneur de toute piste
Cordialement.
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1409329760.8368.1.camel@yco-sts-linux.ianco.homelinux.org
je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn.
Chaque coté du tunnel est un serveur debian (old-stable et jessie).
Le serveur (firewall) est coté old-stable, le client coté jessie.
Le serveur dessert les réseaux 192.168.3.0/24, 192.168.4.0/24 et
192.168.1.0/24
Le vpn est dans le plan d'@ 192.168.100.0/24
Le client (sky) dessert le réseau 192.168.29.0/24.
la table de routage coté serveur est la suivante :
root@firewall:/etc/openvpn# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.100.2 0.0.0.0 255.255.255.255 UH 0 0 0
tun0
192.168.100.0 192.168.100.2 255.255.255.0 UG 0 0 0
tun0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0
eth2
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
192.168.29.0 192.168.100.2 255.255.255.0 UG 0 0 0
tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
eth1
la table de routage coté client est la suivante :
root@sky:~# netstat -rn
Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fenêtre irtt
Iface
0.0.0.0 192.168.29.1 0.0.0.0 UG 0 0 0
br0
192.168.1.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.3.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.4.0 192.168.100.21 255.255.255.0 UG 0 0 0
tun0
192.168.29.0 0.0.0.0 255.255.255.0 U 0 0 0
br0
192.168.100.1 192.168.100.21 255.255.255.255 UGH 0 0 0
tun0
192.168.100.21 0.0.0.0 255.255.255.255 UH 0 0 0
tun0
Les routes viennent de la configuration openvpn via les directives :
push route pour .4, .3, .1
route et iroute pour .29
via fwbuilder la table de routage est configurée de chaque coté pour ne
rien bloquer (enfin c'est ce que je crois).
De chaque coté j'ai mis en place un tshark sur l'interface tun0 et un
sur l'interface eth0 ou br0. Objectif suivre les paquets "icmp".
Les pings et les pongs depuis le client (sky) vers l'adresse du serveur
(firewall) en .3 passent.
Les pings depuis firewall vers sky sur l'adresse en .29 ne sont pas
envoyés sur tun0 de firewall.
Les pings depuis une machine sur le .29 vers une machine sur le .3,
entrent sur br0 de sky, passent sur tun0 de sky mais ne sortent pas de
tun0 de firewall.
Je sèche sur ce problème depuis un bon paquets d'heures.
Je suppose que le problème est coté serveur (firewall) mais je ne sais
plus où chercher.
Je suis donc preneur de toute piste
Cordialement.
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1409329760.8368.1.camel@yco-sts-linux.ianco.homelinux.org
Quelle est ta conf de routage iptables ?
Quelle est ta conf openvpn.conf ?
Le 08/29/2014 06:29 PM, Yann Cohen a écrit :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Bonsoir,
ci après les conf...
Coté serveur
:~# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere
multiport dports ssh
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Coté client
:~# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Serveur
:~# grep -v -e "#" -e ";" -e"^
$" /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
dh dh1024.pem
server 192.168.100.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.3.0 255.255.255.0"
push "route 192.168.4.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
client-config-dir ccd
route 192.168.29.0 255.255.255.0
push "route 192.168.29.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 4
ccd
iroute 192.168.29.0 255.255.255.0
Client
:~# grep -v -e "#" -e ";" -e"^
$" /etc/openvpn/connect/clients.d/sky.lys-net/client.conf
client
dev tun
proto udp
remote xx.yy.zz.www 1194
resolv-retry infinite
cipher DES-EDE3-CBC
ca ca.crt
cert sky.lys-net.crt
key sky.lys-net.key
tls-auth ta.key 1
nobind
persist-key
persist-tun
comp-lzo
verb 3
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Bonsoir
Pour ce que tu veux faire il faut passer par des interfaces tap. En tun
tu peux le faire, mais il faut rajouter des règles de firewall
spécifiques aux clients tun, cela devient une usine à gaz.
--
Daniel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Pardon ?
Les interfaces tap sont utiles pour simuler un lien ethernet sur le VPN,
et notamment pour faire du pontage avec ce lien.
Si c'est juste pour du trafic IP routé ça n'apporte rien par rapport à
des interfaces tun, et les règles iptables nécessaires sont les mêmes
dans les deux cas.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Les tables de routage du serveur et du client VPN semblent correctes.
Pour vérifier le routage d'une adresse donnée, exécuter la commande :
ip route get <adresse>
sur chaque machine Linux impliquée dans le chemin entre la source
(incluse) et la destination.
Pour les règles iptables, merci de fournir la sortie d'iptables-save qui
est plus complète et plus lisible qu'iptables -L.
Là j'ai un gros doute. Si ça entre dans le tunnel, ça doit en sortir.
Sinon c'est le VPN qui ne fait pas son boulot.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
@Yann on a toujours pas eu ta conf iptables ni ta conf openvpn ;)
Le 08/30/2014 04:30 PM, Pascal Hambourg a écrit :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Voici les compléments de configuration.
De plus, il me semble avoir omis une information :
les serveurs, dont firewall, sont des machines virtuelles (xen 4.0.1) et
après une nuit de sommeil, je me rappelle avoir eu des problèmes avec
UDP sur ce type de configuration (les requêtes snmp ne fonctionnaient
pas bien).
Le samedi 30 août 2014 à 16:30 +0200, Pascal Hambourg a écrit :
Coté du réseau client sur une machine en .29
:~$ ip route get 192.168.3.50
192.168.3.50 via 192.168.29.10 dev wlan0 src 192.168.29.100
cache
Sur sky (client vpn @.29.10):
:~# ip route get 192.168.3.50
192.168.3.50 via 192.168.100.21 dev tun0 src 192.168.100.22
cache
Sur firewall (serveur vpn @ .3.70, .4.70 et .1.70)
:~# ip route get 192.168.29.20
192.168.29.20 via 192.168.100.2 dev tun0 src 192.168.100.1
cache mtu 1500 advmss 1460 hoplimit 64
Sur une machine du reseau .3
:~# ip route get 192.168.29.20
192.168.29.20 via 192.168.3.70 dev eth0 src 192.168.3.50
cache mtu 1500 advmss 1460 hoplimit 64
iptables-save
Le client :
:~# iptables-save
# Generated by iptables-save v1.4.21 on Sun Aug 31 07:41:53 2014
*raw
:PREROUTING ACCEPT [234993:26026712]
:OUTPUT ACCEPT [136592:22661450]
-A PREROUTING -p icmp -j TRACE
-A PREROUTING -p icmp -j TRACE
-A OUTPUT -p icmp -j TRACE
-A OUTPUT -p icmp -j TRACE
COMMIT
# Completed on Sun Aug 31 07:41:53 2014
# Generated by iptables-save v1.4.21 on Sun Aug 31 07:41:53 2014
*filter
:INPUT DROP [100:5164]
:FORWARD DROP [79014:9588079]
:OUTPUT DROP [122:12336]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state NEW -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW -j ACCEPT
COMMIT
# Completed on Sun Aug 31 07:41:53 2014
Le serveur
:~# iptables-save
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*raw
:PREROUTING ACCEPT [5697445:3943580901]
:OUTPUT ACCEPT [2767699:2626019169]
-A PREROUTING -p icmp -j TRACE
-A OUTPUT -p icmp -j TRACE
COMMIT
# Completed on Sun Aug 31 07:46:02 2014
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*nat
:PREROUTING ACCEPT [13814184:1193564665]
:POSTROUTING ACCEPT [4542101:299178859]
:OUTPUT ACCEPT [690955:44154381]
-A PREROUTING -d 192.168.1.70/32 -p tcp -m tcp --sport 20 --dport
1024:65535 -j DNAT --to-destination 192.168.4.40
-A PREROUTING -d 192.168.1.70/32 -p tcp -m tcp -m multiport --dports
1143,1080,1025,21,20,80,443,143,993,110,995,25,465 -j DNAT
--to-destination 192.168.4.40
-A PREROUTING -s 192.168.3.0/24 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 192.168.3.70:3128
-A POSTROUTING -o eth1 -j SNAT --to-source 192.168.1.70
COMMIT
# Completed on Sun Aug 31 07:46:02 2014
# Generated by iptables-save v1.4.8 on Sun Aug 31 07:46:02 2014
*filter
:INPUT DROP [1:373]
:FORWARD DROP [88:4584]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state NEW -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW -j ACCEPT
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Sun Aug 31 07:46:02 2014
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
le nom du fichier ccd qui contient les options spécifique du client doit
être le full qualified name du client qui se connecte : avec le nom de
domaine complet.
Yann.
Le vendredi 29 août 2014 à 18:29 +0200, Yann Cohen a écrit :
[...]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 05/09/2014 13:20, Yann COHEN a écrit :
En fait ça dépend surtout de comment tu as nommé le certif icat client Ã
sa création (champ "Common Name") : c'est la dessus que le ccd se ba se
pour pousser les options spécifiques au client.
@+
Christophe.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/