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

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



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 ?

> 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.

> - 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.

> Comment visualiser l'état des tables de NAT ?

# cat /proc/net/nf_conntrack
ou
# conntrack -L

> 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
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.


Reply to: