[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problème réseau



Pascal Hambourg a écrit :
> pascal a écrit :

>>>
>>> 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é.
> 
> Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'avais corrigé...A tel point que je n'avais même pas vu l'erreur.
> 

> Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
> la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
> de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
> de leur comportement particulier (elles ne voient passer que le premier
> paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
> expose à des effets de bord. En particulier la création et la
> suppression de règles NAT n'ont aucune influence sur les paquets
> appartenant ou liés aux connexions déjà établies : les paquets des
> connexions existantes continuent d'être NATés de la même façon.
> 
> Exemple pratique :
> Pendant que la règle SNAT est en place, l'utilisatrice établit une
> connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
> la règle SNAT est supprimée. Malgré cela, tant que la connexion
> existante reste établie, la translation d'adresse et de port mise en
> place pour elle par le passage du premier paquet reste active et
> l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.
> 
> Il faut plutôt introduire ces adresses dans les règles de filtrage de la
> chaîne FORWARD, y compris celles gérant l'état ESTABLISHED,RELATED sinon
> les connexions existantes continueront à passer. Et lors de la coupure
> utiliser la cible REJECT au lieu de DROP afin de signaler que le
> connexion est coupée, c'est plus poli.

Ca me parle cet exemple :-)
Et en plus j'avais (au moins) assimilé cet aspect du NAT. Néanmoins...
Heu en fait elles y sont ces règles. Mais bon comme je craignais
qu'elles fassent double emplois et pour ne pas aggraver mon cas je ne
les ai pas présentées içi. Oui je sais...

Mais là, à cette heure, je ne suis plus à ça près ...

En plus (faut pas taper) elles n'ont pas la bonne forme :
 iptables -A FORWARD -i $LAN_IFACE  -o $INET_IFACE -m state --state !
INVALID -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE  -m state --state
ESTABLISHED,RELATED -j ACCEPT

Et si je ne craignais pas d'abuser...
Il faut donc que ces deux systèmes de règle soient présents (l'un pour
le SNAT et l'autre pour le filtrage) à la fois ? Et il n' y a pas là de
redondance, alors ?
Mais dans la chaîne FORWARD de la table filter,  puis-je distinguer les
deux machines (via "-s") ou suis-je contraint comme dans les lignes
précédentes à raisonner en termes d'interface d'entrée et de sortie du
routeur ?

Merci encore pour ton attention.
En fait je crois avoir du mal à m'imaginer les relations exactes et
précises liant les tables aux chaînes. A m'en faire une représentation
mentale. Ca n'est pas très clair pour moi. Malgré mes lectures.

>> 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 ?
> 
> Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
> 2004, et je n'ai jamais participé à des discussions sur ces sites.
> 

OK. Au temps pour moi.
Hé bien bonne nuit...Ou ce qu'il en reste.
P.




Reply to: