Discussion :

[bill2134]

Bonjour,

J'ai grandement besoin t'aide svp ...

J'ai un problème avec openvpn et interface de sortie,
j’espère trouver ici une réponse et merci pour votre aide.


Voici le schéma actuellement en place :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Host1				 	Host0
 
eth0 --\                              /-- eth0
tap0 --- br0   <--> Internet <--> br0 --- tap0 Serveur
br0  --/                              \-- br0
tap1 --/

Host1 :
- br0 = 188.165.202.x
- tap0 = 10.8.0.2 tunnel openvpn (client)
- tap1 = 79.x.y.z Interface pour un vps qemu/kvm avec une IP du reseau de Host0

Host0 :
- br0 = 91.a.b.c
- tap0 = 10.8.0.1 tunnel openvpn (serveur)


Pour le test :

free.fr --> Internet -> serveur vpn -->client vpn --> serveur hote --> vps


Le problème :
Lors d'un ping l'interface de sortie n'est pas la bonne interface
donc pas de réponse au ping.


La requete vient de tap0 et sort par eth0

Ping depuis une connexion free :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
free:~# ping 79.x.y.z
PING 79.x.y.z (79.x.y.z) 56(84) bytes of data.
^C
--- 79.x.y.z ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3003ms
 
free:~# tcpdump -n icmp
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:46:16.430494 IP 192.168.0.2 > 79.x.y.z: ICMP echo request, id 60779, seq 4999, length 64
14:46:17.430450 IP 192.168.0.2 > 79.x.y.z: ICMP echo request, id 60779, seq 5000, length 64
14:46:18.429951 IP 192.168.0.2 > 79.x.y.z: ICMP echo request, id 60779, seq 5001, length 64

Pas de réponse.

Serveur Openvpn :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
openvpn:~# tcpdump -n icmp -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
15:51:46.739035 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 5156, length 64
15:51:47.739793 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 5157, length 64
15:51:48.740547 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 5158, length 64

La requête icmp est bien visible

Serveur Host1 Interface tap0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
root@ovh1:~# tcpdump -i tap0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:38:52.885329 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4528, length 64
14:38:53.885097 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4529, length 64
14:38:54.886386 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4530, length 64

La requête icmp est bien visible

Serveur Qemu/Kvm sur tap1 vps (qemu/kvm)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
root@ns2001:~# tcpdump -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:33:55.471000 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4233, length 64
15:33:55.471532 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4233, length 64
15:33:56.472399 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4234, length 64
15:33:56.472517 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4234, length 64
15:33:57.488661 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 60779, seq 4235, length 64
15:33:57.488796 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4235, length 64

Ok, le VPS répond bien au ping

Serveur Host1 Interface eth0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
root@ovh1:~# tcpdump -i eth0 -n icmp
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:41:36.269280 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4691, length 64
14:41:37.280951 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4692, length 64
14:41:38.282116 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4693, length 64
14:41:39.286983 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4694, length 64
14:41:40.297008 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4695, length 64
14:41:41.298019 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4696, length 64

La réponse passe par ETH0, la route par defaut.
Pourquoi elle ne passe pas par TAP0 ?
A la limite que ça passe par ETH0 c'est pas grave à partir du moment au j'ai une réponse au ping (chez free) mais ce n'est pas le cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
root@host:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         188.165.202.254 0.0.0.0         UG    0      0        0 br0
10.9.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tap0
188.165.202.0   0.0.0.0         255.255.255.0   U     0      0        0 br0

echo > /proc/sys/net/ipv4/ip_forward est bien à 1


J'ai essayer MARK de iptable sans succès, ça sort toujours par eth0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
iptables -t mangle -A PREROUTING -i tap0 -j MARK --set-mark 1
ip route add table mytest default dev tap0
ip rule add fwmark 1 table mytest
ip route flush cache

Merci pour vos réponses.

JP

[Invité]

Salut,

beaucoup de données à décrypter...

C'est tout à fait normal que l'ICMP Reply prenne la route par défaut. En effet, le Reply a pour adresse destination 82.236.ip.free (ça doit être mappé avec 192.168.0.2 non ?) qui est inconnue de la table de routage.

Les paquets émis par ce host sortiront par TAP0 **si et seulement si** l'adresse destination appartient au réseau 10.9.0.0. D'ailleurs ce serait pas 10.8.0.0 ?

Autre chose qui m'interpelle, c'est le message "no IPv4 address assigned" concernant ETH0... C'est normal ?

Enfin, quelle est la table de routage du serveur VPN ? C'est pour info afin de mieux appréhender la topologie level 3...

Steph

[bill2134]

Merci pour la réponse.

l'adresse destination appartient au réseau 10.9.0.0. D'ailleurs ce serait pas 10.8.0.0 ?

C'est bien 10.9, erreur de copie

Autre chose qui m'interpelle, c'est le message "no IPv4 address assigned" concernant ETH0... C'est normal ?

l'IP publique est sur br0 de chaque coté.

Enfin, quelle est la table de routage du serveur VPN ? C'est pour info afin de mieux appréhender la topologie level 3...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
openvpn:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         79.x.y.66   0.0.0.0         UG    0      0        0 br0
10.9.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tap0
79.x.y.64   0.0.0.0         255.255.255.252 U     0      0        0 br0

Pourtant, c'est presque bon, il y a bien une réponse mais sur la mauvaise interface

Host tap0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

14:46:18.429951 IP 192.168.0.2 > 79.x.y.z: ICMP echo request, id 60779, seq 5001, length 64

Host eth0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

14:41:41.298019 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 60779, seq 4696, length 64

D'autres infos :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
# TAP0
tcpdump -n icmp -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:11:28.844415 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 604, length 64
20:11:29.845178 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 605, length 64
20:11:30.849130 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 606, length 64

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# ETH0
tcpdump -n icmp -vv -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:11:48.882584 IP (tos 0x0, ttl 64, id 56122, offset 0, flags [none], proto ICMP (1), length 84)
    79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 624, length 64
20:11:49.882798 IP (tos 0x0, ttl 64, id 56123, offset 0, flags [none], proto ICMP (1), length 84)
    79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 625, length 64
20:11:50.882064 IP (tos 0x0, ttl 64, id 56124, offset 0, flags [none], proto ICMP (1), length 84)
    79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 626, length 64
20:11:51.882758 IP (tos 0x0, ttl 64, id 56125, offset 0, flags [none], proto ICMP (1), length 84)
    79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 627, length 64
20:11:52.883404 IP (tos 0x0, ttl 64, id 56126, offset 0, flags [none], proto ICMP (1), length 84)
    79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 628, length 64

Sur br0 : (in sur tap0 et out sur eth0)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
tcpdump -n icmp -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:12:02.898618 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 638, length 64
20:12:02.898642 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 638, length 64
20:12:03.899805 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 639, length 64
20:12:03.899827 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 639, length 64
20:12:04.898828 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 640, length 64
20:12:04.898855 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 640, length 64
20:12:05.899962 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 641, length 64
20:12:05.899983 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 641, length 64
20:12:06.898611 IP 82.236.ip.free > 79.x.y.z: ICMP echo request, id 17669, seq 642, length 64
20:12:06.898636 IP 79.x.y.z > 82.236.ip.free: ICMP echo reply, id 17669, seq 642, length 64

[Invité]

C'est bien 10.9, erreur de copie

Tu veux dire que les TAP0 des hosts, c'est 10.9.0.1 et 10.9.0.2 (au lieu de 10.8) ?

Dans ta topologie, pourquoi tu ne tires pas le VPN le long d'Internet avec des interfaces Tunnels ?

Je suis encore "jeune" en Unix mais j'ai déployé des choses très similaires avec du Cisco en utilisant des tunnels GRE/IPSec, j'essaie donc de comprendre tes objectifs...

Steph

[bill2134]

Merci pour la réponse

Tu veux dire que les TAP0 des hosts, c'est 10.9.0.1 et 10.9.0.2 (au lieu de 10.8) ?

Oui

Dans ta topologie, pourquoi tu ne tires pas le VPN le long d'Internet avec des interfaces Tunnels ?

Ce n'est pas mon but

j'essaie donc de comprendre tes objectifs...

Le tunnel Openvpn est un L2

Le but est d'avoir une IP du réseau de de Host0 sur le vps du reseau de Host1
Est c'est bien le cas, l'ip 79.x.y.z du vps sur Host1 appartient au réseau de Host0.

C'est pour avoir un seul réseau quelque-soit l'endroit ou est hébergé le serveur Host1, l'ip de vps sera toujours la même.

N'y a t-il aucun moyen de dire un noyau linux que les paquets provenant de tap0 doivent sortir par tap0 et non pas par eth0 ?
Ou est il possible de modifier les paquets [sortant par eth0] pour qu'ils soit acceptés par 82.236.ip.free ?

[Invité]

Ok, understood... Donc ton objectif c'est

PC distant - Internet - Serveur VPN <-- L2 VPN --> Client VPN - VPS

N'y a t'il aucun moyen de dire un noyau linux que les paquets provenant de tap0 doivent sortir par tap0 et non pas par eth0 ?

Comme j'avais expliqué dans mon 1er post, c'est cette entrée de la table de routage qui fait que ce trafic est injecté sur ETH0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Destination	Passerelle	Genmask		Indic	Metric	Ref	Use	Iface
0.0.0.0 	79.x.y.66 	0.0.0.0		UG	0	0	0	br0

En gros, lorsque le Host doit forwarder du trafic vers une destination qu'il ne connait pas, il l'injecte dans le switch virtuel BR0. Donc oui, ça ressemble à un problème de routage

Gardons l'interface 79.x.y.66 comme "next hop" pour la route par défaut et essayons d'envoyer ce trafic au travers de TAP0 :

route add default gw 79.x.y.66 dev tap0

Refais les tests et dis-nous comment ça se passe... La marche arrière est facile, il suffira de retirer cette route par défaut qu'on a rajoutée.

Steph

[bill2134]

Merci pour la réponse

# Sur le serveur Openvpn

route add default gw 79.x.y.66 dev tap0

SIOCADDRT: Aucun processus de ce type

J'ai du nouveau,

[1] Le VPS dans le serveur Host1 ping si je lui met une IP + gateway du réseau de Host0, c'est bien ce que je cherche sauf que tout le trafic sortant du VPS passe par tap0(VPN) du serveur Host1

[2] Le VPS dans le serveur Host1 ping aussi si je lui met une IP + gateway du réseau de Host1, mais dans ce cas je ne peut plus mettre l'IP du réseau de Host0 (car les paquets sortent par eth0 de serveur hôte)


Dans le cas 2, t'ai testé avec (dans le VPS de Host1) :

ip addr add 79.x.y.z/26 dev eth0

echo "2 mynet" >> /etc/iproute2/rt_tables

iptables -t mangle -A PREROUTING -i eth0 -d 79.x.y.z -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i eth0 -d 79.x.y.z -j LOG --log-level DEBUG --log-prefix "Fwmark 2 : "
ip route add default via 79.x.y.126 dev eth0 table mynet
ip rule add fwmark 2 table mynet

ip route flush cache

Mais sans succès... icmp qui vient de [Host1]tap0 sort toujours par [Host1]eth0, pourtant la règle semble bien être détecté :

Mar 11 19:20:40 ns2001 kernel: [ 1220.165596] Fwmark 2 : IN=eth0 OUT= MAC=00:50:AB:CD:EFD:00:30:48:85:AB:CD:EFD SRC=82.236.ip.free DST=79.x.y.z LEN=84 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=47459 SEQ=2 MARK=0x2

JP

[Invité]

SIOCADDRT: Aucun processus de ce type

Là, je sais pas. 79.x.y.66 est bien une adresse valide que tu peux pinger depuis le serveur non ?

[1] Le VPS dans le serveur Host1 ping si je lui met une IP + gateway du réseau de Host0, c'est bien ce que je cherche sauf que tout le trafic sortant du VPS passe par tap0(VPN) du serveur Host1

[2] Le VPS dans le serveur Host1 ping aussi si je lui met une IP + gateway du réseau de Host1, mais dans ce cas je ne peut plus mettre l'IP du réseau de Host0 (car les paquets sortent par eth0 de serveur hôte)

Oui, je comprends que tu auras besoin de faire du routage conditionnel.
Sur du Cisco, on appelle ça du PBR (Policy Based Routing)... Mais je ne suis pas assez calé sur Unix pour te faire des recommandations, désolé.

Alors en ce qui concerne le ping entre la machine free et le VPS, il suffirait simplement d'ajouter une route statique spécifique du style

ip route add 79.x.y.z (/32 ou /26 selon que tu veux une entrée spécifique à free ou au réseau) via 10.9.0.2

à condition bien sûr que 10.9.0.2 soit joignable depuis le serveur Host1.

Steph

[bill2134]

Bonjour,

Merci pour les conseils reçu, le problème est résolu

- Mauvais masque dans la config IP du VPS
- Ajout de ligne de code dans le fichier rc.local

#/etc/rc.local
ip addr add 79.x.y.z/25 dev eth0
ip route add default via 79.x.y.gateway dev eth0 table mynet
iptables -t mangle -A OUTPUT -o eth0 -s 79.x.x.z -j MARK --set-mark 1
ip rule add fwmark 1 table mynet
ip route flush table cache

JP

[Invité]

Merci pour le retour.

En relisant les symptômes du problème et la façon dont ça a été résolu, j'ai encore du mal à saisir... Mais c'est sans doute lié à mon manque d'expertise sur Linux...

Steph