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

Re: Comment visualiser le contenu du NAT d'iptables ?






Le 19 juin 2014 10:04, Pascal Hambourg <pascal@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=""> > 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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: [🔎] 53A2997E.1000404@plouf.fr.eu.org" target="_blank">https://lists.debian.org/[🔎] 53A2997E.1000404@plouf.fr.eu.org



Reply to: