2006/2/3, Pascal Hambourg <pascal.mail@plouf.fr.eu.org>:
Stéphane BERDIN a écrit :
>
>>Note : du point de vue du routage et du filtrage les alias de la forme eth0:x
> n'existent pas, c'est eth0 qui compte. Un alias ne crée par une nouvelle interface,
> il ne fait qu'ajouter une adresse à une interface existante dont il partage les
> paramètres (flags, MTU, etc.).
>
> Ça veux dire que je n'ai pas besoin de modifier netfilter ?
Ça dépend des règles iptables. Si elles ne considèrent que les
interfaces et pas les adresses, ce qui est le cas des tiennes, alors
effectivement elles n'ont pas besoin d'être modifiées.
Note : Netfilter n'est que l'infrastructure générique de traitement des
paquets réseau sur laquelle vient se greffer iptables (et/ou ipchains,
ip6tables...) qui gère les règles de filtrage/nat/mangle IP.
>>Si tu veux qu'on trouve ce qui manque, tu peux publier les sorties de :
>>- ifconfig et route -n sur une machine de A, une de B et la passerelle
>>- iptables-save sur la passerelle
>
> Sur les machine A : 192.168.5.0/24 et passerelle 192.168.5.102
> Sur les machine B : 192.168.8.0/24
et passerelle 192.168.8.8
>
> Route -n me donne :
>
> Destination Passerelle Genmask Iface
> 192.168.5.0
* 255.255.255.0 eth0
> Localnet * 255.255.255.0 eth0
> Default
192.168.8.30 eth0
Sur quelle machine ? La passerelle ?
Je doute que l'option -n renvoie "Localnet" et "Default". Que représente
"Localnet" ? Si c'est la table de routage de passerelle, je suppose
qu'il s'agit de 192.168.8.0.
> 192.168.8.30 étant le routeur après la passerelle qui est relié à internet.
> La sortie iptables-save :
Original que le routeur soit sur sur le même réseau que le reste.
> *nat
> :PREROUTING ACCEPT [2701135:314954246]
> :POSTROUTING ACCEPT [1836254:129765162]
> :OUTPUT ACCEPT [1777094:126977546]
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -j
> REDIRECT --to-ports 3128
L'option --tcp-flags n'est pas très utile dans une règle NAT. Seul le
premier paquet d'une connexion traverse les chaînes de la table nat, et
si ce n'est pas un paquet SYN il devrait de toute façon être rejeté par
une règle de filtrage ou la pile TCP/IP du destinataire.
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [32:3360]
> :OUTPUT DROP [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth0 -j ACCEPT
> -A INPUT -i eth0 -j ACCEPT
Doublon.
> -A INPUT -i eth0 -p tcp -m tcp --dport 3128 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
Inutile, la règle précédente accepte déjà tout en entrée sur eth0.
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Inutile si lo et eth0 sont les seules interfaces puisque des règles
précédentes acceptent déjà tout en entrée sur ces deux interfaces.
> -A FORWARD -i eth0 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -p tcp -m tcp --dport 9900 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -p tcp -m tcp --dport 8500 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -p udp -m udp --dport 53 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -p udp -m udp --dport 3128 -j ACCEPT
> -A FORWARD -i eth0 -o eth0 -j ULOG
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Note : cette règle est placée de préférence dans en tête de liste car
pour la grande majorité des paquets, qui sont dans l'état ESTABLISHED,
cela évite de dérouler les autres règles.
Il n'y a pas de règle autorisant l'ICMP echo-request, normal que le ping
ne passe pas entre A et B. Il ne doit pas non plus passer depuis A ou B
vers l'extérieur.
iptables -A FORWARD -i eth0 -o eth0 -p icmp --icmp-type echo-request \
-j ACCEPT
Par contre les protocoles explicitement autorisés devraient passer.
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -o eth0 -j ACCEPT
> -A OUTPUT -o eth0 -j ACCEPT
Doublon.
> -A OUTPUT -o eth0 -j ULOG
> -A OUTPUT -o lo -j ULOG
> -A OUTPUT -o eth0 -p tcp -m tcp --dport 80 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
> -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
Toutes ces règles sont sans effet, des règles précédentes acceptent déjà
tout en sortie sur les interfaces lo et eth0.
> -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Inutile si lo et eth0 sont les seules interfaces puisque des règles
précédentes acceptent déjà tout en sortie sur ces deux interfaces.
D'après ces règles, l'accès au web à travers le proxy transparent
devrait fonctionner pour 192.168.5.0/24
, à condition que squid soit
configuré pour accepter les requêtes provenant de ces adresses.
Par contre, les autres protocoles autorisés ne fonctionneront que si
le routeur 192.168.8.30
a une route vers 192.168.5.0/24. Ou bien en
ajoutant une règle iptables SNAT pour masquer l'adresse source :
iptables -t nat -A POSTROUTING -o eth0 -s
192.168.5.0/24 \
-d 192.168.8.30 -j SNAT --to-source 192.168.8.8
Par contre les communications entre A et B sur les ports autorisés
devraient fonctionner.
Pour finir, attention aux éventuels ICMP redirect qui pourraient être
émis par la passerelle à l'émetteur d'un paquet quand les interfaces
d'entrée et de sortie sont identiques. Cet ICMP, s'il est accepté, a
pour conséquence de créer dans la table de routage de l'émetteur une
route directe vers la destination du paquet avec le routeur comme
passerelle, court-circuitant la passerelle pour cette destination.
Super Pascal pour cette analyse fine.
Le fait que le routeur soit sur le même lan n'est guère rassurant. Le pc qui joue le rôle de parefeu peut-il accepter une carte réseau supplémentaire afin d'y connecter le routeur.
La réponse de Pascal pour le SNAT me semble la plus appropriée. Penser à contrôler que le noyau est correctement configuré pour cela car j'ai déjà eu la blague.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org