Discussion :

[dumoulex]

Bonjour,

Je rencontre un soucis assez particulier, peut être quel quelqu'un a une idée..

schéma explicatif :
Pièce jointe 137704

J'utilise un PC (appelons le PC_passerelle) disposant de 2 interfaces :
- une interface eth0 avec IP 10.30.0.18
- une interface wifi wlan0 avec IP 172.17.0.18

D'autres machines (PC_test_1 & PC_test_2) sont sur le même réseau local avec des IPs à elles (voir schéma), et ont l'IP de PC_passerelle renseigné comme passerelle.

Lorsque je monte mon interface wifi , j'ajoute la règle iptables suivante :

Code :

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

IPTABLES -t nat -A POSTROUTING -s 10.33.0.0/16 -o wlan0 -j MASQUERADE

(je la supprime lorsque je démonte l'interface)


Grâce à cela, je peux, depuis PC_test_1 et PC_test_2, réussir à joindre les équipements sur le réseau wifi en passant par PC_passerelle

Cette partie fonctionne parfaitement ; je peux faire des pings...

Mon problème, c'est que :
Si je lance un ping continu depuis PC_test_1 sur 172.17.0.2 ; que je relance mon interface wifi ; le ping ne marche plus.
Pour le refaire marcher , il faut que je coupe le ping, puis que je patiente 30 secondes. Une fois ce délai attendu, je peux relancer le ping qui fonctionne à nouveau.

Il y a peut être une sorte de tunnel ou de session créé par le ping (avec un timeout de 30 secondes), qui reste actif..

Quelqu'un voit il de quoi je parle ou a-t-il rencontré le même problème ?

merci d'avance,

Nico

[dumoulex]

petite avancée..

si je modifie le timeout du ping de PC_passerelle contenu dans : /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout

(valeur à 30 par defaut)

2 tests :
je met une valeur à 10 secondes :
je lance mon test, le ping est interrompu, et je dois le coupé pendant 10 secondes avant de le relancer pour que celui ci fonctionne à nouveau.

je met une valeur à 5 secondes :
je lance mon test, le ping est interrompu, mais repart tout seul au bout de 5 secondes.

Le 2eme cas ne me convient pas tout à fait même s'il fait ce que je souhaite (j'aime savoir pourquoi mon système réagit comme il le fait)

J'en déduis qu'il y a un autre timeout quelque part, qui interagit avec ip_conntrack_icmp_timeout

Reste à trouver lequel et ou il est...