Le 19 juin 2014 10:04, Pascal Hambourg <pas...@plouf.fr.eu.org> a écrit :
> Olivier a écrit :
> >
> > 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=157.55.235.149
> > 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.
>
> Routeur source = la box, destination = le routeur Debian ?
>
oui c'est ça
>
> > 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é)
>
> Oui, excepté qu'il s'agit de paquets et non de requêtes. Netfilter et
> iptables ne savent pas ce qu'est une requête.
>
C'est vrai.
>
> > - 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
>
> Pour être précis, le suivi de connexion de netfilter (conntrack) ne
> 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.
>
Intéressant !
cf plus bas.
>
> > Comment visualiser l'état des tables de NAT ?
>
> # cat /proc/net/nf_conntrack
>
Ca marche parfaitement !
> ou
> # conntrack -L
>
nécessite sans doute le paquet conntrack
>
> > Est-il possible-souhaitable d'augmenter la durée de rétention des
> > correspondance du NAT avec iptables ?
>
> On peut modifier différents délais via
> /proc/sys/net/netfilter/nf_conntrack_<protocol>/timeout_*. En ce qui
>
# ls /proc/sys/net/netfilter/nf_conntrack_tcp*
/proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_last_ack
/proc/sys/net/netfilter/nf_conntrack_tcp_loose
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_max_retrans
/proc/sys/net/netfilter/nf_conntrack_tcp_max_retrans
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_recv
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_unacknowledged
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_fin_wait
> 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.
>
Ca doit être ça car j'ai:
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
432000
Cela signifie-t-il qu'en pratique, pour du TCP,, une entrée de la table du
NAT :
- est effacée dès que le routeur a reconnu une fin de connexion TCP
- est effacée après 5 jours si rien ne s'est passé pour cette connexion ?
>
> --
> 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-requ...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
> Archive: https://lists.debian.org/53a2997e.1000...@plouf.fr.eu.org
>
>
