[RÉSOLU] pas de partage de connexion via iptables sous lenny

Bonjour à tous,

Je tente de partager ma connexion internet avec les machines de mes fils via un point d’accès sans fil d-link DWG700AP.
Description : La machine hôte dispose de 2 cartes réseaux ; eth0 (en dhcp connectée sur une neuf box) et eth1 (ip fixe 192.168.168.1 en éthernet sur le pa). Les machines clientes ont des cartes wifi D-link (ip fixe 192.168.168.60 et 61) et des dual-boot testing/XP.

Globalement le réseau fonctionne et depuis les postes clients je ping(ue) les interfaces réseau du PA et de la machine internet.

Le problème que je rencontre est que je ne parviens pas à partager ma connexion ( même après avoir compulsé plusieurs sites relatant du paramétrage d’iptables :
comme ici ou encore .)

J’ai paramétré le fichier /etc/sysctl.conf (net.ipv4.ip_forward=1) pour autoriser le forwarding mais rien n’y fait… J’ai surement un soucis d’iptables mais je cale… Une bonne âme accepterait-elle de me donner un coup de main pour faire en sorte que cela fonctionne… Merci

Ci dessous mon iptables-start

[code]#!/bin/sh

/etc/network/if-pre-up.d/iptables-start

Script qui démarre les règles de filtrage “iptables”

#: Interfaces
#: eth0 (dhcp bail attribué => 192.168.1.4/255.255.255.0 -> Internet
#: eth1 (static vers réseau) 192.168.168.1/255.255.255.0 -> localnet

#: Flush pour remise à 0
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -t nat -F
iptables -t nat -Z
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -Z
iptables -t mangle -X
iptables -F
iptables -Z
iptables -X

On drop tout par défaut

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Pas de filtrage sur lo

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

scans XMAS et NULL

iptables -A INPUT -i eth0 -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

#Syn flood tcp et udp
#iptables -A INPUT -i eth0 -p tcp --syn -m limit --limit 3/s -j ACCEPT
#iptables -A INPUT -i eth0 -p udp -m limit --limit 10/s -j ACCEPT

autorise vers Internet

iptables -A OUTPUT -o eth0 -d 0.0.0.0/0 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i eth0 -s 0.0.0.0/0 -m state --state RELATED,ESTABLISHED -j ACCEPT

autorise vers localnet

iptables -A OUTPUT -o eth1 -s 192.168.168.0/24 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.168.0/24 -m state --state ! INVALID -j ACCEPT

partage de connexion

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ! INVALID -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[/code]

depuis un poste client je ne parviens pas à pinguer l’interface publique (eth0)…

[quote=“lau@x2”]Le problème que je rencontre est que je ne parviens pas à partager ma connexion

iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ! INVALID -j ACCEPT

[/quote]
Normal, aucune de ces règles n’autorise le trafic sortant en provenance du réseau local. Je suppose que la présence de eth0 au lieu de eth1 dans la seconde est une coquille.

Ça n’a rien à voir avec le partage de connexion (forwarding). On ne pingue pas une interface mais une adresse. Dans ce cas précis, la machine doit répondre avec l’adresse pinguée comme source en sortie sur l’interface localnet (eth1). Or la règle citée ci-dessus bloque le paquet à cause de l’option -s. Pourquoi cette restriction ?

Je te remercie d’avoir pris le temps de lire et d’analyser mon problème pour me donner cette réponse :slightly_smiling:

On avance car maintenant j’arrive à pinguer l’adresse de l’interface publique (bien sur je ne faisait pas un ping de eth0 mais de l’adresse de cette interface :wink: )

J’ai donc viré la restrection de l’adresse source sur :

aisi que la coquille (sigh, je l’ai réécrit au moins 4 fois :blush: )

iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -m state --state ! INVALID -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Pourtant en dépit de cette avancée, je ne parviens pas à surfer à partir d’un poste client. Un autre idée (voire un autre coquille ? ) :slightly_smiling:

Surfer, tout de suite… Et si on commençait par des choses plus basiques comme ping et traceroute ? (résultat complet en cas de problème SVP)

Alors, du poste client 192.168.168.61 (default gateway = 192.168.168.1)

ping de l’interface réseau du PA (192.168.168.50) =ok
ping de l’interface réseau local de la machine internet (192.168.168.1) =ok
ping de l’interface connectée à la 9box de la machine internet (192.168.1.4) =ok

ping de 212.30.96.108 (dns primaire 9)=nok
tracert de 212.30.96.108 ne voit que 192.168.168.1

tu ‘ping’ des deux cotés de ta machine internet c’est bien, mais ce sont des interfaces directement reliées à celle çi . et dès que tu essaye d’aller plus loin (passer un autre routeur qui est ta 9 box) ça ne fonctionne plus.

sans doute au niveau des tables de routage de ta machine internet. il faut une passerelle par defaut.
que donne ‘route -n’

voici l’information demandée

x2:/home/lau# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

où 192.168.1.1 est l’adresse de l’interface lan de la 9 box

lau@x2, la passerelle a bien accès à internet ?
Peux-tu examiner le trafic sur l’interface internet (eth0) de la passerelle avec tcpdump pendant le traceroute ?

J’ai résolu le problème, merci beaucoup pour ton aide. En fait j’ai mis une réservation DHCP sur la 9box pour l’interface de connexion à internet sur la machine partageant sa connexion et je suis passé en SNAT dans l’iptables-start ce qui donne en fait :

Maintenant que j’ai une configuration qui fonctionne, je vais pouvoir affiner la protection et paramétrer iptables sur les postes clients.

Pour les personnes qui rencontreraient le même problème, j’ai l’impression que le module masquerade n’était pas chargé dans mon noyau (lsmod |grep masq =""") et qu’en conséquence le disfonctionnement observé venait de là (piste à apronfondir…).

Je suis bien content que cela fonctionne et je trouve super cette entr’aide que l’on trouve sur ce forum ; le tout dans une atmosphère de respect partagé ce qui n’est que plus plaisant encore…

Merci à ceux qui m’ont lus et se sont posés la question de savoir s’ils pouvaient aider…

Le module de masquerading fait partie des noyaux Debian standards et devrait être chargé automatiquement lors de la création de la règle avec “-j MASQUERADE”. Donc à moins d’une erreur lors de la création de cette règle (pas de message d’erreur ?), il aurait dû être chargé.

“lsmod |grep masq” n’affichera rien de toute façon car le module s’appelle ipt_MASQUERADE. Il aurait fallu spécifier “grep -i” (insensible à la casse) ou “grep MASQ”.

Ceci dit, la réservation d’adresse simplifiera les redirections de port sur le routeur le cas échéant.