Olivier a écrit :
>Routeur source = la box, destination = le routeur Debian ?
> J'ai un réseau dont le routeur principal est une machine sous Wheezy.
>
> Ce routeur effectue du NAT au profit d'utilisateurs d'un réseau WiFi.
> Le NAT est implémenté par une règle IPtables du type:
> iptables -t nat -A POSTROUTING -o ${WAN_IF} -j SNAT --to-source ${WAN_IP}
>
> J'observe dans les logs une multitude de lignes comme:
>
> Jun 18 16:19:57 foo kernel: [4670104.045210] Denied TCP: IN=eth0 OUT=
> MAC=c0:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC=""> > DST=192.168.1.243 LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=55546 DF PROTO=TCP
> SPT=40001 DPT=51296 WINDOW=35 RES=0x00 ACK FIN URGP=0
>
> Les adresses MAC visibles sont bien celles de ma destination et du routeur
> source.
Oui, excepté qu'il s'agit de paquets et non de requêtes. Netfilter et
> J'interprète ces lignes de la façon suivante:
>
> - un utilisateur du WiFi émet une requête vers Internet,
>
> - l'IP source de la requête est modifiée par mon routeur sous Wheezy qui
> enregistre au passage la correspondance dans une table avant d'envoyer la
> requête modifiée au modem-routeur du lien ADSL (très chargé)
iptables ne savent pas ce qu'est une requête.
Pour être précis, le suivi de connexion de netfilter (conntrack) ne
> - si la réponse en provenance d'Internet est trop tardive (ou pour une
> autre raison à identifier) alors IP tables ne retrouve l'entrée idoine dans
> sa table de correspondance et écarte la réponse
retrouve pas l'entrée qui a été effacée et classe donc le paquet dans
l'état NEW ou INVALID, selon le protocole et le paquet. Ensuite le jeu
de règles iptables en place fait le reste. En général il est écrit de
sorte que les paquets dans l'état INVALID sont bloqués, ainsi que les
paquets entrants dans l'état NEW ne correspondant pas à des services
autorisés. Même sans ces règles, sur un routeur NAT, l'adresse finale
étant perdue le paquet aurait été délivré à la machine locale qui n'est
pas à l'origine de la connexion, et qui donc l'aurait écarté.
Ici, on voit qu'il s'agit d'un paquet TCP FIN, signalant la fin d'une
connexion TCP. Il peut s'agir d'un doublon d'une vieille connexion déjà
terminée.
# cat /proc/net/nf_conntrack
> Comment visualiser l'état des tables de NAT ?
ou
# conntrack -L
On peut modifier différents délais via
> Est-il possible-souhaitable d'augmenter la durée de rétention des
> correspondance du NAT avec iptables ?
/proc/sys/net/netfilter/nf_conntrack_<protocol>/timeout_*. En ce qui
concerne TCP qui est un protocole "connecté", je ne ne crois pas qu'il y
a lieu d'augmenter nf_conntrack_tcp_timeout_established qui vaut déjà 5
jours.
Archive: [🔎] 53A2997E.1000404@plouf.fr.eu.org" target="_blank">https://lists.debian.org/[🔎] 53A2997E.1000404@plouf.fr.eu.org
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org