Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Pb de routage entre deux sites via openvpn

Pb de routage entre deux sites via openvpn

9 réponses
Avatar
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
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Johnny B
Salut,

Quelle est ta conf de routage iptables ?

Quelle est ta conf openvpn.conf ?


Le 08/29/2014 06:29 PM, Yann Cohen a écrit :
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 :
:/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 :
:~# 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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Yann Cohen
Le vendredi 29 août 2014 à 21:13 +0200, Johnny B a écrit :
Salut,


Bonsoir,

ci après les conf...

Quelle est ta conf de routage iptables ?


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


Quelle est ta conf openvpn.conf ?


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




Le 08/29/2014 06:29 PM, Yann Cohen a écrit :
> 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 :
> :/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 :
> :~# 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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Daniel Huhardeaux
Le 29/08/2014 18:29, Yann Cohen a écrit :
Bonjour,



Bonsoir

[...]

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



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/
Avatar
Pascal Hambourg
Daniel Huhardeaux a écrit :

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.



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/
Avatar
Pascal Hambourg
Yann Cohen a écrit :
Bonjour,

je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn. [...]



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.

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.



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/
Avatar
Johnny B
Hello,

@Yann on a toujours pas eu ta conf iptables ni ta conf openvpn ;)




Le 08/30/2014 04:30 PM, Pascal Hambourg a écrit :
Yann Cohen a écrit :
Bonjour,

je sèche sur un problème de routage entre deux sites qui sont connectés
via openvpn. [...]


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.

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.


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/
Avatar
Yann Cohen
Bonjour,

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 :
Yann Cohen a écrit :
> Bonjour,
>
> je sèche sur un problème de routage entre deux sites qui sont connectés
> via openvpn. [...]

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>



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


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.

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

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/
Avatar
Yann COHEN
Résolu :
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 :
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 :


[...]

--
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/
Avatar
Christophe
Bonsoir,

Le 05/09/2014 13:20, Yann COHEN a écrit :

Résolu :
le nom du fichier ccd qui contient les options spécifique du clien t doit
être le full qualified name du client qui se connecte : avec le no m de
domaine complet.

Yann.




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/