Comment visualiser le contenu du NAT d'iptables ?

Le
Olivier
--001a1133fa5e7f5bec04fc221341
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

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.


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 Whe=
ezy 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=
é)

- 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 i=
doine dans
sa table de correspondance et écarte la réponse


Comment valider ou invalider ma théorie ?

Comment visualiser l'état des tables de NAT ?

Est-il possible-souhaitable d'augmenter la durée de rétention des
correspondance du NAT avec iptables ?

Slts

--001a1133fa5e7f5bec04fc221341
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div>Bonjour,<br><br></div>J&#39;ai un rÃ=
©seau dont le routeur principal est une machine sous Wheezy.<br><br></div=
>Ce routeur effectue du NAT au profit d&#39;utilisateurs d&#39;un rése=
au WiFi.<br>
</div>Le NAT est implémenté par une règle IPtables du type:<=
br>iptables -t nat -A POSTROUTING -o ${WAN_IF} -j SNAT --to-source ${WAN_IP=
}<br><br><br></div>J&#39;observe dans les logs une multitude de lignes comm=
e:<br>








<p>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=
</p><p>Les adresses MAC visibles sont bien celles de ma destination et du r=
outeur source.</p><p><br></p><p>J&#39;interprète ces lignes de la fa=
çon suivante:</p>
<p>- un utilisateur du WiFi émet une requête vers Internet,</p><p=
>- l&#39;IP source de la requête est modifiée par mon routeur sou=
s Wheezy qui enregistre au passage la correspondance dans une table avant d=
&#39;envoyer la requête modifiée au modem-routeur du lien ADSL (t=
rès chargé)<br>
</p><p>- si la réponse en provenance d&#39;Internet est trop tardive (=
ou pour une autre raison à identifier) alors IP tables ne retrouve l&#=
39;entrée idoine dans sa table de correspondance et écarte la r=
éponse</p><p><br></p>
<p>Comment valider ou invalider ma théorie ?<br></p><p>Comment visuali=
ser l&#39;état des tables de NAT ?</p><p>Est-il possible-souhaitable d=
&#39;augmenter la durée de rétention des correspondance du NAT av=
ec iptables ?</p>
<p>Slts<br></p><div><p></p></div></div>

--001a1133fa5e7f5bec04fc221341--

--
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: https://lists.debian.org/CAPeT9jhbPbziSbTsP7CZ6GXs_X7rLP6wD+vtNo5OneoW6gUNLw@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
daniel huhardeaux
Le #26204462
Le 18/06/2014 22:26, Olivier a écrit :
Bonjour,



Bonsoir


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À:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC7.55.235.149
DST2.168.1.243 LEN@ TOS=0x00 PREC=0x00 TTLR IDU546 DF
PROTO=TCP DPTQ296 WINDOW5 RES=0x00 ACK FIN URGP=0

Les adresses MAC visibles sont bien celles de ma destination et du
routeur source.




SPT et DPT, à quoi correspondent ils? Denied: est ce la 1ère requête
faite par le client?

un tshark -i eth0 src or dst 157.55.235.149 te permettrait de voir le
trafic, s'il est bidirectionnel, etc ...


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é)

- 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


Comment valider ou invalider ma théorie ?

Comment visualiser l'état des tables de NAT ?




Voir dans /proc/sys/net/[ipv4|ipv6|netfilter]

Est-il possible-souhaitable d'augmenter la durée de rétention des
correspondance du NAT avec iptables ?

Slts




--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Gilles Mocellin
Le #26204742
Le 18/06/2014 22:26, Olivier a écrit :
Bonjour,

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À:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC7.55.235.149
DST2.168.1.243 LEN@ TOS=0x00 PREC=0x00 TTLR IDU546 DF
PROTO=TCP DPTQ296 WINDOW5 RES=0x00 ACK FIN URGP=0

Les adresses MAC visibles sont bien celles de ma destination et du
routeur source.


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é)

- 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


Comment valider ou invalider ma théorie ?

Comment visualiser l'état des tables de NAT ?

Est-il possible-souhaitable d'augmenter la durée de rétention des
correspondance du NAT avec iptables ?

Slts




Bonsoir,

Je pense qu'avec le paquet netstat-nat, tu dois pouvoir trouver ton
bonheur :

aptitude show netstat-nat
Paquet : netstat-nat
État: non installé
Version : 1.4.10-3
Priorité : optionnel
Section : net
Responsable : Gustavo Paniagua dos Santos Architecture : amd64
Taille décompressée : 28,7 k
Dépend: libc6 (>= 2.14)
Est en conflit: netstat-nat
Description : tool that display NAT connections
Netstat-nat is a program that displays Network Address Translations
(NAT) connections, managed by netfilter/iptables acting as firewall.

NAT rules are stored in memory. However, the program reads its
information from '/proc/net/ip_conntrack', which is the temporary
conntrack-storage of netfilter.
Site : http://www.tweegy.nl/projects/netstat-nat/

Étiquettes: admin::monitoring, implemented-in::c,
interface::commandline, network::firewall, role::program,
scope::utility, security::firewall, use::monitor


--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Pascal Hambourg
Le #26205292
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À:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC7.55.235.149
DST2.168.1.243 LEN@ TOS=0x00 PREC=0x00 TTLR IDU546 DF PROTO=TCP
DPTQ296 WINDOW5 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.

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Olivier
Le #26206182
--001a11c3b364c30a0404fc30edfc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 19 juin 2014 10:04, Pascal Hambourg
Olivier a écrit :
>
> J'ai un réseau dont le routeur principal est une machine sous Whee zy.
>
> Ce routeur effectue du NAT au profit d'utilisateurs d'un réseau Wi Fi.
> 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_I P}
>
> 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À:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC7.55.235.149
> DST2.168.1.243 LEN@ TOS=0x00 PREC=0x00 TTLR IDU546 DF PROTO=TCP
> DPTQ296 WINDOW5 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 cha rgé)

Oui, excepté qu'il s'agit de paquets et non de requêtes. Netfil ter 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 don c le paquet dans
l'état NEW ou INVALID, selon le protocole et le paquet. Ensuite le j eu
de règles iptables en place fait le reste. En général il e st écrit de
sorte que les paquets dans l'état INVALID sont bloqués, ainsi q ue les
paquets entrants dans l'état NEW ne correspondant pas à des ser vices
autorisés. Même sans ces règles, sur un routeur NAT, l'adr esse 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 tabl e du
NAT :
- est effacée dès que le routeur a reconnu une fin de connexion T CP
- est effacée après 5 jours si rien ne s'est passé pour cett e 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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/





--001a11c3b364c30a0404fc30edfc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class="">&gt;<br>
&gt; J&#39;ai un réseau dont le routeur principal est une machine sous Wheezy.<br>
&gt;<br>
&gt; Ce routeur effectue du NAT au profit d&#39;utilisateurs d&#39;un rà ©seau WiFi.<br>
&gt; Le NAT est implémenté par une règle IPtables du type:<b r>
&gt; iptables -t nat -A POSTROUTING -o ${WAN_IF} -j SNAT --to-source ${WAN_ IP}<br>
&gt;<br>
&gt; J&#39;observe dans les logs une multitude de lignes comme:<br>
&gt;<br>
&gt; Jun 18 16:19:57 foo kernel: [4670104.045210] Denied TCP: IN=eth0 OUT =<br>
&gt; MACÀ:3f:d5:60:36:37:40:5a:9b:bb:60:a1:08:00 SRC7.55.235.149<b r>
&gt; DST2.168.1.243 LEN@ TOS=0x00 PREC=0x00 TTLR IDU54 6 DF PROTO=TCP<br>
&gt; DPTQ296 WINDOW5 RES=0x00 ACK FIN URGP=0<br>
&gt;<br>
&gt; Les adresses MAC visibles sont bien celles de ma destination et du rou teur<br>
&gt; source.<br>
<br>

<div class=""><br>
&gt; J&#39;interprète ces lignes de la façon suivante:<br>
&gt;<br>
&gt; - un utilisateur du WiFi émet une requête vers Internet,<br>
&gt;<br>
&gt; - l&#39;IP source de la requête est modifiée par mon routeur sous Wheezy qui<br>
&gt; enregistre au passage la correspondance dans une table avant d&#39;env oyer la<br>
&gt; requête modifiée au modem-routeur du lien ADSL (très ch argé)<br>
<br>
iptables ne savent pas ce qu&#39;est une requête.
<div class=""><br>
&gt; - si la réponse en provenance d&#39;Internet est trop tardive (ou pour une<br>
&gt; autre raison à identifier) alors IP tables ne retrouve l&#39;entr ée idoine dans<br>
&gt; sa table de correspondance et écarte la réponse<br>
<br>
</div>Pour être précis, le suivi de connexion de netfilter (connt rack) ne<br>
retrouve pas l&#39;entrée qui a été effacée et classe d onc le paquet dans<br>
l&#39;état NEW ou INVALID, selon le protocole et le paquet. Ensuite le jeu<br>
de règles iptables en place fait le reste. En général il est écrit de<br>
sorte que les paquets dans l&#39;état INVALID sont bloqués, ainsi que les<br>
paquets entrants dans l&#39;état NEW ne correspondant pas à des s ervices<br>
autorisés. Même sans ces règles, sur un routeur NAT, l&#39;a dresse finale<br>
étant perdue le paquet aurait été délivré à l a machine locale qui n&#39;est<br>
pas à l&#39;origine de la connexion, et qui donc l&#39;aurait éca rté.<br>
<br>
Ici, on voit qu&#39;il s&#39;agit d&#39;un paquet TCP FIN, signalant la fin d&#39;une<br>
connexion TCP. Il peut s&#39;agir d&#39;un doublon d&#39;une vieille connex ion déjà<br>
terminée. <div class=""><br>
&gt; Comment visualiser l&#39;état des tables de NAT ?<br>
<br>

ou<br>
# conntrack -L
<div class=""><br>
&gt; Est-il possible-souhaitable d&#39;augmenter la durée de réte ntion des<br>
&gt; correspondance du NAT avec iptables ?<br>
<br>
</div>On peut modifier différents délais via<br>
/proc/sys/net/netfilter/nf_conntrack_&lt;protocol&gt;/timeout_*. En ce qui< br></blockquote><div><br># ls /proc/sys/net/netfilter/nf_conntrack_tcp*<br> /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal      Â Â Â Â  /proc/sys/net/netfilter/nf_conntrack_tcp_timeou t_last_ack<br>
/proc/sys/net/netfilter/nf_conntrack_tcp_loose       Â        /proc/sys/net/netfilter/nf_conntra ck_tcp_timeout_max_retrans<br>/proc/sys/net/netfilter/nf_conntrack_tcp_max_ retrans          /proc/sys/net/netf ilter/nf_conntrack_tcp_timeout_syn_recv<br>
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close          /proc/sys/net/netfilter/nf_conntrack_tcp_tim eout_syn_sent<br>/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wai t   /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait<br >
/proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established  /proc/sy s/net/netfilter/nf_conntrack_tcp_timeout_unacknowledged
concerne TCP qui est un protocole &quot;connecté&quot;, je ne ne crois pas qu&#39;il y<br>
a lieu d&#39;augmenter nf_conntrack_tcp_timeout_established qui vaut dà ©jà 5<br>
jours.<br></blockquote><div><br>Ca doit être ça car j&#39;ai:<br> # cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established<br>43200 0 <br></div><div><br><br></div><div>Cela signifie-t-il qu&#39;en pratique, pour du TCP,, une entrée de la table du NAT :<br>

<div class=""><br>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS <br>
</blockquote></div><br></div></div>

--001a11c3b364c30a0404fc30edfc--

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAPeT9jjyiP6O_Q=ZMWYghtGo-1hn0entrKLUyX+
Pascal Hambourg
Le #26206462
Olivier a écrit :

# conntrack -L



nécessite sans doute le paquet conntrack



Oui.

Cela signifie-t-il qu'en pratique, pour du TCP,, une entrée de la table du
NAT :



Ce n'est pas une table de NAT, c'est la table de conntrack qui sert
aussi au 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 ?



En résumé, oui. Il y a encore divers délais à la fermeture de la
connexion (nf_conntrack_tcp_timeout_*) pour attendre d'éventuels
segments en retard (les paquets n'arrivent pas forcément dans l'ordre),
l'acquittement de la fermeture par l'autre côté... avant d'effacer l'entrée.

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Publicité
Poster une réponse
Anonyme