Re: problème réseau
Pascal Hambourg a écrit :
>> Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
>> les adresses des deux cartes ethernet. Je ne savais pas que tout passait
>> par lo.
>
> Quand je disais que ce point était souvent mal compris. ;-)
A juste titre donc...
>
>> lo Lien encap:Boucle locale
>> inet adr:127.0.0.1 Masque:255.0.0.0
>> adr inet6: ::1/128 Scope:Hôte
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>>
>> Ce qui laisse penser que "lo" est active.
>
> Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
> ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
> pour lo, mais pas pour une interface ethernet classique). Une interface
> réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
> la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
> portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.
ok. Du coup j'avais également des problèmes avec gnome celui-ci
utilisant vraisemblablement différentes sockets pour sa cuisine interne
fort gènées par la fermeture de l'interface loopback. C'est également
résolu.
>
>> Par "sans règle" j'entendais à la suite de :
>>
>> iptables -F INPUT
>> iptables -F OUTPUT
>> iptables -F FORWARD
>
> Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
> toutes les chaînes de la table 'filter'.
>
>> iptables -P INPUT ACCEPT
>> iptables -t nat -F
>
> Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
> modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
> le trafic sortant et routé.
Je connaissais le premier point puisque si non précisé la table "filter"
est la table par défaut. Par contre j'ignorais le second et je pensais
naïvement que le flush concernait aussi les politiques par défaut.
>
>>> Je ne vois pas de règle autorisant le trafic sur lo en sortie.
>
> J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
> trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
> pourquoi la communication entre la machine et le LAN est impossible.
re bien vu.
>
>>> Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
>>> ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?
>>
>> Bien vu !
>
> Hé, on ne me la fait pas comme ça à moi. ;-)
Oui je m'en suis aperçu.
>
> Un petit détail concernant les règles de NAT source :
>> -A POSTROUTING -s 192.162.2.21 -o eth0 -j SNAT --to-source 192.168.1.20
>> -A POSTROUTING -s 192.162.2.23 -o eth0 -j SNAT --to-source 192.168.1.20
> ^^^
> Je pense qu'il y a une petite erreur de frappe dans les adresses des
> options -s : 192.162 au lieu de 192.168.
Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !
>
> Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
> Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
> faire dans les règles de filtrage plutôt que dans les règles de NAT.
> Ici, les paquets vont sortir sans être NATés et les réponses vont se
> perdre dans la nature si la Livebox n'a pas la route qui va bien pour
> les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
> passer à cause de l'erreur dans les règles SNAT.
Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...
Si l'erreur est corrigée ils seront bien Natés tout de même, non ?
Voili voilà. Encore merci pour toutes ces précisions.
Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?
P.
Reply to: