POSTROUTING ne fonctionne pas comme escompté sur une interface tun

Le
Eric Belhomme
Bonjour,

J'ai un petit soucis de POSTROUTING avec une interface tun

Voici le contexte :
- tun1 est créé par openvpn
- eth1 est une patte sur mon LAN


4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:1e:58:df:e1:80 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.1/24 brd 172.16.1.255 scope global eth1:0

17: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 100
link/[65534]
inet 172.24.253.1 peer 172.24.253.2/32 scope global tun1

le LAN distant (192.168.96.0/24) doit pouvoir joindre le LAN local
(192.168.1.0/24). Voici les routes :

172.24.253.2 dev tun1 proto kernel scope link src 172.24.253.1
172.24.253.0/29 via 172.24.253.2 dev tun1
192.168.96.0/24 via 172.24.253.2 dev tun1
172.16.1.0/24 dev eth1 proto kernel scope link src 172.16.1.1
192.168.0.0/18 via 172.16.1.254 dev eth1

La passerelle distante a donc comme IP 172.24.253.2, mais aussi
192.168.96.254. Ses routes sont :
172.16.0.0/16 172.24.253.1 UG
172.24.253.1 172.24.253.2 UH
192.168.0.0/19 172.24.253.1 UG
192.168.96.0/24 link#1 U

Donc fort logiquement, lorsqu'elle tente de se connecter à une machine
du réseau 192.168.1.0/24, elle le fait via sont interface tun (172.24.253.2)

Le problème, c'est que le réseau 172.24.253.0/29 n'est connu que de mes
passerelles, et je souhaite qu'il en soit ainsi. J'ai donc rajouté une
règle iptables pour SNATter ces connexions :

iptables -t nat -A POSTROUTING -o eth1 -s 172.24.253.2 -d 192.168.1.0/24
-j SNAT --to-source 192.168.96.254

Mais cette règle ne semble jamais appliquée ! pourtant un tcpdump me
donne ceci :
sudo tcpdump -ni eth1 icmp
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:09:45.260597 IP 172.24.253.2 > 192.168.1.192: ICMP echo request, id
17184, seq 0, length 64

On voit bien, sur l'interface eth1, un paquet sortir par eth1 avec comme
adresse source 172.24.253.2 et comme destination une adresse inclue dans
mon netmask 192.168.1.0/24 !
Alors où est l'erreur ?

Merci pour vos suggestions :)

--
Rico
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #20194841
[Attention : suivi positionné dans fr.comp.os.linux.configuration]

Salut,

Eric Belhomme a écrit :

iptables -t nat -A POSTROUTING -o eth1 -s 172.24.253.2 -d 192.168.1.0/24
-j SNAT --to-source 192.168.96.254

Mais cette règle ne semble jamais appliquée ! pourtant un tcpdump me
donne ceci :
sudo tcpdump -ni eth1 icmp
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:09:45.260597 IP 172.24.253.2 > 192.168.1.192: ICMP echo request, id
17184, seq 0, length 64

On voit bien, sur l'interface eth1, un paquet sortir par eth1 avec comme
adresse source 172.24.253.2 et comme destination une adresse inclue dans
mon netmask 192.168.1.0/24 !



Tu as bien lancé le ping *après* avoir ajouté la règle SNAT ?
Il y a d'autres règles iptables qui pourraient empêcher celle-ci d'être
efficace ?
Pas de pont ?
Tu as essayé d'instrumenter la traversée d'iptables avec la cible TRACE
si disponible et/ou avec des règles LOG dans toutes les tables/chaînes,
notamment avant et après la règle SNAT ?
Eric Belhomme
Le #20195121
Pascal Hambourg a écrit :

Tu as bien lancé le ping *après* avoir ajouté la règle SNAT ?
Il y a d'autres règles iptables qui pourraient empêcher celle-ci d'être
efficace ?



Chain POSTROUTING (policy ACCEPT 60962 packets, 3631K bytes)
pkts bytes target prot opt in out source
destination
0 0 SNAT all -- * eth1:1 172.24.253.2
0.0.0.0/0 to:192.168.96.254
0 0 SNAT all -- * eth2 192.168.1.0/24
0.0.0.0/0 to:(ip publique)
18190 1091K MASQUERADE all -- * eth3 0.0.0.0/0
0.0.0.0/0

La règle est bien là, insérée en 1ere position, et aucun paquet ne l'a
traverée. Le SNAT sur mon IP publique ne pose pas de problème, tout
comme le MASQUERADE sur une autre IP publique

Pas de pont ?



non, pas de pont. Par contre il y a des IP flottantes, du contrackd, du
keepalived, et du policy routing...

Tu as essayé d'instrumenter la traversée d'iptables avec la cible TRACE
si disponible et/ou avec des règles LOG dans toutes les tables/chaînes,
notamment avant et après la règle SNAT ?



qu'est ce que tu suggères ?

--
Rico
Pascal Hambourg
Le #20195351
Eric Belhomme a écrit :

pkts bytes target prot opt in out source destination
0 0 SNAT all -- * eth1:1 172.24.253.2 0.0.0.0/0 to:192.168.96.254


[...]
La règle est bien là, insérée en 1ere position, et aucun paquet ne l'a
traverée.



Cela ne correspond pas à la règle que tu avais citée qui contenait
"eth1" (bon) alors que celle-ci contient "eth1:1" (pas bon). iptables ne
connaît pas les alias [1] mais seulement les vraies interfaces, normal
que cette règle ne capte aucun paquet. Normalement tu aurais dû avoir un
gros message d'avertissement de ce type :

Warning: weird character in interface `eth1:1' (No aliases, :, ! or *).

[1] Rappel : pour Linux, un alias IP de la forme eth1:1 n'est pas une
interface mais une simple etiquette attachée à une adresse IP configurée
sur une interface.
Eric Belhomme
Le #20203731
Pascal Hambourg a écrit :
Eric Belhomme a écrit :
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * eth1:1 172.24.253.2 0.0.0.0/0 to:192.168.96.254


[...]
La règle est bien là, insérée en 1ere position, et aucun paquet ne l'a
traverée.



Cela ne correspond pas à la règle que tu avais citée qui contenait
"eth1" (bon) alors que celle-ci contient "eth1:1" (pas bon). iptables ne
connaît pas les alias [1] mais seulement les vraies interfaces, normal
que cette règle ne capte aucun paquet. Normalement tu aurais dû avoir un
gros message d'avertissement de ce type :

Warning: weird character in interface `eth1:1' (No aliases, :, ! or *).



Tu as parfaitement raison, j'ai simplement fait un copier/coller alors
que je faisais le test, au cas où...
Mais ce que j'ai décrit correspond bien à la réalité, j'aurais dû
corrigé ma copie de terminal pour éviter ce malentendu ;)

[1] Rappel : pour Linux, un alias IP de la forme eth1:1 n'est pas une
interface mais une simple etiquette attachée à une adresse IP configurée
sur une interface.



merci pour ce rappel

--
Rico
Pascal Hambourg
Le #20204461
Eric Belhomme a écrit :



Tu as parfaitement raison, j'ai simplement fait un copier/coller alors
que je faisais le test, au cas où...
Mais ce que j'ai décrit correspond bien à la réalité, j'aurais dû
corrigé ma copie de terminal pour éviter ce malentendu ;)



Pour être sûr d'avoir bien compris, tu veux dire que la vraie règle qui
devrait marcher mais ne marche pas contient eth1 et non eth1:1 ?
Eric Belhomme
Le #20209011
Pascal Hambourg a écrit :
Eric Belhomme a écrit :
Tu as parfaitement raison, j'ai simplement fait un copier/coller alors
que je faisais le test, au cas où...
Mais ce que j'ai décrit correspond bien à la réalité, j'aurais dû
corrigé ma copie de terminal pour éviter ce malentendu ;)



Pour être sûr d'avoir bien compris, tu veux dire que la vraie règle qui
devrait marcher mais ne marche pas contient eth1 et non eth1:1 ?



oui !

--
Rico
Pascal Hambourg
Le #20210541
Eric Belhomme a écrit :
Pascal Hambourg a écrit :
Pour être sûr d'avoir bien compris, tu veux dire que la vraie règle qui
devrait marcher mais ne marche pas contient eth1 et non eth1:1 ?



oui !



Alors je n'ai pas d'idée. Suivre le cheminement des paquets à travers
les chaînes iptables peut rapporter des informations supplémentaires.
J'utiliserais quelque chose de ce genre :


iptables -t filter -I INPUT -j LOG --log-prefix "[INPUT filter] "
iptables -t filter -I FORWARD -j LOG --log-prefix "[FORWARD filter] "
iptables -t filter -I OUTPUT -j LOG --log-prefix "[OUTPUT filter] "

iptables -t nat -I PREROUTING -j LOG --log-prefix "[PREROUTING nat] "
iptables -t nat -I OUTPUT -j LOG --log-prefix "[OUTPUT nat] "
iptables -t nat -I POSTROUTING -j LOG --log-prefix "[POSTROUTING1 nat] "
iptables -t nat -A POSTROUTING -j LOG --log-prefix "[POSTROUTING2 nat] "
# les deux dernieres c'est pour avant et apres la regle SNAT

iptables -t mangle -I PREROUTING -j LOG --log-prefix "[PREROUTING mangle] "
iptables -t mangle -I INPUT -j LOG --log-prefix "[INPUT mangle] "
iptables -t mangle -I FORWARD -j LOG --log-prefix "[FORWARD mangle] "
iptables -t mangle -I OUTPUT -j LOG --log-prefix "[OUTPUT mangle] "
iptables -t mangle -I POSTROUTING -j LOG --log-prefix "[POSTROUTING
mangle] "

Ou bien avec la cible TRACE (si elle marche, je n'ai pas réussi à avoir
quoi que ce soit dans les logs) :

iptables -t raw PREROUTING -j TRACE
iptables -t raw OUTPUT -j TRACE
Publicité
Poster une réponse
Anonyme