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
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 SPT@001 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
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
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
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 SPT@001 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
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
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 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 ?
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
SPT@001 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 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 ?
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 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 ?
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 ?
> 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.
> - 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.
> 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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">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/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/
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=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 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.
> - 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.
> 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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/53A2997E.1000404@plouf.fr.eu.org
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 ?
> 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.
> - 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.
> 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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">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/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/
# conntrack -L
nécessite sans doute le paquet conntrack
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 ?
# conntrack -L
nécessite sans doute le paquet conntrack
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 ?
# conntrack -L
nécessite sans doute le paquet conntrack
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 ?