Forum Linux.général [resolu] openvpn : pb de routage.

Posté par  .
Étiquettes : aucune
-1
5
mai
2012

Bonjour,

Je cherche à mettre en place un réseau de ce style:

Serveur Openvpn Serveur de VMs réseau virtuel

Côté VPN, le serveur openvpn et le serveur de vms sont reliés dans
le subnet 10.10/16, la connection est fonctionnelle.
Côté serveur de VMs, les VMs sont connecté entre elles et à l'hôté
par un switch VDE (switch virtuel) et configurées sur le subnet 10.100/16.
Ce montage est fonctionnelle, les VMs communiquent bien entre elles et avec
l'hôte ainsi qu'avec le monde extérieur avec les règles de NAT qui vont bien.

Par contre le problème se situe lorsque j'essaye de faire communiquer les VMs
avec le serveur OpenVPN.
Les routes sont configurées et l'ip_forward activé sur le serveur de VMs, et je
vois bien (avec tcpdump) partir les paquets à destination du ServeurVPN, sur
l'interface tun0 d'openvpn mais je ne les vois pas de l'autre côté oO
Idem dans l'autre sens.
Je soupçonne un problème du côté de la configuration VPN mais je n'ai pas réussi
à mettre la main dessus.

routes sur le serveur VPN:
root@noc:/home/sprdrx# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.251.182 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
10.100.0.0 10.10.1.1 255.255.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.251.182 0.0.0.0 UG 0 0 0 eth0

routes sur le serveur de VMs:
root@phy000:/home/sprdrx/vms# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
XX.XX.XX.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.100.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tapSWITCH
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
0.0.0.0 XX.XX.XX.1 0.0.0.0 UG 0 0 0 eth0

configuration openvpn côté serveur:
# This file is managed by Puppet. DO NOT EDIT.
ca /etc/openvpn/vpn.example.net/keys/ca.crt
cert /etc/openvpn/vpn.example.net/keys/server.crt
cipher BF-CBC
client-config-dir /etc/openvpn/vpn.example.net/client-configs
client-to-client
comp-lzo
daemon
dev tun0
dh /etc/openvpn/vpn.example.net/keys/dh1024.pem
keepalive 10 60
key /etc/openvpn/vpn.example.net/keys/server.key
local XX.XX.XX.XX
lport 1194
management /var/run/openvpn-vpn.example.net.sock unix
persist-key
persist-tun
ping-timer-rem
proto tcp-server
script-security 3
server 10.10.00.0 255.255.0.0
tls-server
topology subnet
up "/etc/init.d/syslog-ng reload"

et côté client:
# This file is managed by Puppet. DO NOT EDIT.
ca keys/ca.crt
cert keys/phy000.example.net.crt
client
comp-lzo
dev tun
key keys/phy000.example.net.key
mute 20
mute-replay-warnings
nobind
ns-cert-type server
persist-key
persist-tun
proto tcp
remote noc.example.net 1194
resolv-retry infinite
verb 3

voici ce que vois tcpdump:

root@phy000:/home/sprdrx/vms# tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
17:10:58.138342 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 186, length 64
17:10:59.146328 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 187, length 64
17:11:00.154460 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 188, length 64
17:11:01.162449 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 189, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Si quelqu'un a une idée, merci d'avance, je nage completement là.
Cordialement.

  • # icmp drop ?

    Posté par  . Évalué à 2.

    d'apres :

    root@phy000:/home/sprdrx/vms# tcpdump -ni tun0
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
    17:10:58.138342 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 186, length 64
    17:10:59.146328 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 187, length 64
    17:11:00.154460 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 188, length 64
    17:11:01.162449 IP 10.100.1.12 > 10.10.0.1: ICMP echo request, id 1365, seq 189, length 64

    ton serveur vpn recoit bien les echo request de la machine 10.100.1.12
    sur l'interface 10.10.0.1 (tun0)

    mais il ne semble pas y repondre.

    verifie que ton parefeu ne soit pas configurer pour ignorer les icmp request

    • [^] # Re: icmp drop ?

      Posté par  . Évalué à 0.

      Merci pour ta réponse,

      Mais en fait le dump est réalisé sur le serveur de VMs (j'aurais dû le préciser dsl), le serveurVPN lui ne reçoit rien.
      Au niveau des règles iptables sur le serveur VPN, la première règle de INPUT est de
      tout accepter sur l'interface tun0 (interface d'openvpn), et l'OUTPUT est en openbar.
      Idem sur le serveur de VM (et pas de filtrage sur la table FORWARD).
      Ceci dit j'ai beaucoup de règles (pour d'autres trucs) sur ces machines, je vais tester
      avec un iptables vide pour voir.

      • [^] # Re: icmp drop ?

        Posté par  . Évalué à 0.

        Non, même en passant toutes les policy iptables en ACCEPT sur les deux serveurs, cela ne change rien.

      • [^] # Re: icmp drop ?

        Posté par  . Évalué à 2.

        sauf que le tun0 il est soit sur la machine serveur VPN
        soit sur un client VPN

        hors si tu met ta machine de VMs sur le VPN, ca doit mettre l'embrouille dans toutes les regles

  • # [RESOLU]

    Posté par  . Évalué à 1.

    Problème résolu,

    le routage avec route ne suffit pas, il manquait les directives idoines dans la configuration d'openvpn.
    (ca m'apprendra à lire les docs en diagonales, tiens).
    merci néanmoins à toi NeoX.

    Cdlt.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.