POSTROUTING ne fonctionne pas comme escompté sur une interface tun
7 réponses
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 :
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 ?
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 ?
[Attention : suivi positionné dans fr.comp.os.linux.configuration]
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 ?
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
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 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 ?
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
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 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.
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
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 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.
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
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 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 ?
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
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 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 ?
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
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 :
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
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 :
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 :