Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu peux
confirmer ou infirmer le premier cas en traçant une connexion normale
qui ne passe pas par le VPN.
Dans le second cas, il n'est pas anormal
que le client rejette ces SACK incorrects avec des RST, mais alors
pourquoi la passerelle ne le fait-elle pas aussi lorsqu'elle est
elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Quant au contournement consistant à fortement diminuer la valeur de MTU,
je suppose qu'il avait pour effet de diminuer le taux de paquets perdus.
Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu peux
confirmer ou infirmer le premier cas en traçant une connexion normale
qui ne passe pas par le VPN.
Dans le second cas, il n'est pas anormal
que le client rejette ces SACK incorrects avec des RST, mais alors
pourquoi la passerelle ne le fait-elle pas aussi lorsqu'elle est
elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Quant au contournement consistant à fortement diminuer la valeur de MTU,
je suppose qu'il avait pour effet de diminuer le taux de paquets perdus.
Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu peux
confirmer ou infirmer le premier cas en traçant une connexion normale
qui ne passe pas par le VPN.
Dans le second cas, il n'est pas anormal
que le client rejette ces SACK incorrects avec des RST, mais alors
pourquoi la passerelle ne le fait-elle pas aussi lorsqu'elle est
elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Quant au contournement consistant à fortement diminuer la valeur de MTU,
je suppose qu'il avait pour effet de diminuer le taux de paquets perdus.
Pascal Hambourg a écrit :Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu
peux confirmer ou infirmer le premier cas en traçant une connexion
normale qui ne passe pas par le VPN.
Voici un tcpdump pris sur la passerelle toujours, mais de eth0 cette
fois lors de l'envoi du même mail via le serveur SMTP de mon FAI :
12:55:00.063972 IP 23.128.17-93.rev.gaoland.net.smtp >
gateway.local.53202: . ack 22262 win 204 <nop,nop,timestamp 3347978627
4507929,nop,nop,sack 1 {23702:25142}>
Les valeurs des SACK me paraissent cohérentes cette fois...
Détail que j'ai zappé la dernière fois et qui pourrait avoir son
importance : quand je fais un tcpdump -i tun0, j'ai un warning :
:/home/cyberjujum# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
Que je n'ai pas quand je fais un tcpdump sur eth0. Je ne sais pas trop
ce que ça veut dire et si ça peut expliquer les valeurs de SACK
incohérentes...
Dans le second cas, il n'est pas anormal que le client rejette ces
SACK incorrects avec des RST, mais alors pourquoi la passerelle ne le
fait-elle pas aussi lorsqu'elle est elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Pas de règles iptables sur le poste client, sur la passerelle j'ai juste
les règles postées dans mon premier message. Et si je me connecte au VPN
directement depuis le poste client, pas de problème non plus.
En fait si
je me connecte directement au VPN depuis n'importe quel poste (mon PC de
bureau, mon laptop, la passerelle) il n'y a aucun problème. C'est quand
je mets la passerelle entre les deux que ça pose problème :/
Pascal Hambourg a écrit :
Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu
peux confirmer ou infirmer le premier cas en traçant une connexion
normale qui ne passe pas par le VPN.
Voici un tcpdump pris sur la passerelle toujours, mais de eth0 cette
fois lors de l'envoi du même mail via le serveur SMTP de mon FAI :
12:55:00.063972 IP 23.128.17-93.rev.gaoland.net.smtp >
gateway.local.53202: . ack 22262 win 204 <nop,nop,timestamp 3347978627
4507929,nop,nop,sack 1 {23702:25142}>
Les valeurs des SACK me paraissent cohérentes cette fois...
Détail que j'ai zappé la dernière fois et qui pourrait avoir son
importance : quand je fais un tcpdump -i tun0, j'ai un warning :
root@gateway:/home/cyberjujum# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
Que je n'ai pas quand je fais un tcpdump sur eth0. Je ne sais pas trop
ce que ça veut dire et si ça peut expliquer les valeurs de SACK
incohérentes...
Dans le second cas, il n'est pas anormal que le client rejette ces
SACK incorrects avec des RST, mais alors pourquoi la passerelle ne le
fait-elle pas aussi lorsqu'elle est elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Pas de règles iptables sur le poste client, sur la passerelle j'ai juste
les règles postées dans mon premier message. Et si je me connecte au VPN
directement depuis le poste client, pas de problème non plus.
En fait si
je me connecte directement au VPN depuis n'importe quel poste (mon PC de
bureau, mon laptop, la passerelle) il n'y a aucun problème. C'est quand
je mets la passerelle entre les deux que ça pose problème :/
Pascal Hambourg a écrit :Donc soit ton tcpdump ne calcule pas correctement les valeurs de SACK
qu'il affiche (ce sont des valeurs relatives par rapport au numéro de
séquence initial du SYN) mais ça m'étonnerait, soit quelque chose
trafique les paquets en chemin avant qu'ils entrent dans le VPN. Tu
peux confirmer ou infirmer le premier cas en traçant une connexion
normale qui ne passe pas par le VPN.
Voici un tcpdump pris sur la passerelle toujours, mais de eth0 cette
fois lors de l'envoi du même mail via le serveur SMTP de mon FAI :
12:55:00.063972 IP 23.128.17-93.rev.gaoland.net.smtp >
gateway.local.53202: . ack 22262 win 204 <nop,nop,timestamp 3347978627
4507929,nop,nop,sack 1 {23702:25142}>
Les valeurs des SACK me paraissent cohérentes cette fois...
Détail que j'ai zappé la dernière fois et qui pourrait avoir son
importance : quand je fais un tcpdump -i tun0, j'ai un warning :
:/home/cyberjujum# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
Que je n'ai pas quand je fais un tcpdump sur eth0. Je ne sais pas trop
ce que ça veut dire et si ça peut expliquer les valeurs de SACK
incohérentes...
Dans le second cas, il n'est pas anormal que le client rejette ces
SACK incorrects avec des RST, mais alors pourquoi la passerelle ne le
fait-elle pas aussi lorsqu'elle est elle-même cliente ?
Il y a des règles de filtrage iptables sur la passerelle et le poste
client qui seraient susceptible d'expliquer leur différence de
comportement ?
Pas de règles iptables sur le poste client, sur la passerelle j'ai juste
les règles postées dans mon premier message. Et si je me connecte au VPN
directement depuis le poste client, pas de problème non plus.
En fait si
je me connecte directement au VPN depuis n'importe quel poste (mon PC de
bureau, mon laptop, la passerelle) il n'y a aucun problème. C'est quand
je mets la passerelle entre les deux que ça pose problème :/
Oui, mais ce n'était pas la peine de coller les 1000 lignes...
Or pas de masquerading dans les cas où il n'y a pas de problème. Je
crois que j'ai compris. Le masquerading dépend du suivi de connexion
pour identifier les paquets à modifier. Or depuis le noyau 2.6.9, le
suivi des connexions TCP a été "durci" en ce qui concerne la
vérification de cohérence des numéros de séquence Je suppose que cela
concerne aussi les valeurs dans les SACK. Par conséquent si les numéros
de séquence de SACK sont incohérents, le paquet est classé dans l'état
INVALID et n'est pas traité par le masquerading. Le traitement d'un
paquet retour valide consiste à remplacer l'adresse destination (qui est
celle de l'interface tun0 de la passerelle), par l'adresse initiale du
client. Si en revanche le paquet retour est invalide, il n'est pas
modifié et arrive donc à la couche TCP de la passerelle. Or celle-ci n'a
pas ouvert de connexion correspondante (la couche TCP et iptables sont
indépendants), et c'est elle et non le client qui répond avec un RST.
Ainsi tcpdump sur le client ou l'interface LAN de la passerelle n'aurait
pas vu passer les paquets SACK fautifs ni les RST en réponse.
Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif via
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien noyau
<~ 2.6.20) ou /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1
(noyau récent).
Oui, mais ce n'était pas la peine de coller les 1000 lignes...
Or pas de masquerading dans les cas où il n'y a pas de problème. Je
crois que j'ai compris. Le masquerading dépend du suivi de connexion
pour identifier les paquets à modifier. Or depuis le noyau 2.6.9, le
suivi des connexions TCP a été "durci" en ce qui concerne la
vérification de cohérence des numéros de séquence Je suppose que cela
concerne aussi les valeurs dans les SACK. Par conséquent si les numéros
de séquence de SACK sont incohérents, le paquet est classé dans l'état
INVALID et n'est pas traité par le masquerading. Le traitement d'un
paquet retour valide consiste à remplacer l'adresse destination (qui est
celle de l'interface tun0 de la passerelle), par l'adresse initiale du
client. Si en revanche le paquet retour est invalide, il n'est pas
modifié et arrive donc à la couche TCP de la passerelle. Or celle-ci n'a
pas ouvert de connexion correspondante (la couche TCP et iptables sont
indépendants), et c'est elle et non le client qui répond avec un RST.
Ainsi tcpdump sur le client ou l'interface LAN de la passerelle n'aurait
pas vu passer les paquets SACK fautifs ni les RST en réponse.
Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif via
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien noyau
<~ 2.6.20) ou /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1
(noyau récent).
Oui, mais ce n'était pas la peine de coller les 1000 lignes...
Or pas de masquerading dans les cas où il n'y a pas de problème. Je
crois que j'ai compris. Le masquerading dépend du suivi de connexion
pour identifier les paquets à modifier. Or depuis le noyau 2.6.9, le
suivi des connexions TCP a été "durci" en ce qui concerne la
vérification de cohérence des numéros de séquence Je suppose que cela
concerne aussi les valeurs dans les SACK. Par conséquent si les numéros
de séquence de SACK sont incohérents, le paquet est classé dans l'état
INVALID et n'est pas traité par le masquerading. Le traitement d'un
paquet retour valide consiste à remplacer l'adresse destination (qui est
celle de l'interface tun0 de la passerelle), par l'adresse initiale du
client. Si en revanche le paquet retour est invalide, il n'est pas
modifié et arrive donc à la couche TCP de la passerelle. Or celle-ci n'a
pas ouvert de connexion correspondante (la couche TCP et iptables sont
indépendants), et c'est elle et non le client qui répond avec un RST.
Ainsi tcpdump sur le client ou l'interface LAN de la passerelle n'aurait
pas vu passer les paquets SACK fautifs ni les RST en réponse.
Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif via
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien noyau
<~ 2.6.20) ou /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1
(noyau récent).
Curieux : j'ai le problème quand j'utilise mon PC de bureau (Ubuntu
8.10) et mon laptop (Ubuntu 9.04) comme client. Par contre, avec le PC
de mes parents (Windows XP), aucun problème ! Peut être que Windows XP
n'autorise pas les acquittements sélectifs, ce qui reviendrait au
comportement d'Ubuntu une fois tcp_sack passé à 0...
Curieux : j'ai le problème quand j'utilise mon PC de bureau (Ubuntu
8.10) et mon laptop (Ubuntu 9.04) comme client. Par contre, avec le PC
de mes parents (Windows XP), aucun problème ! Peut être que Windows XP
n'autorise pas les acquittements sélectifs, ce qui reviendrait au
comportement d'Ubuntu une fois tcp_sack passé à 0...
Curieux : j'ai le problème quand j'utilise mon PC de bureau (Ubuntu
8.10) et mon laptop (Ubuntu 9.04) comme client. Par contre, avec le PC
de mes parents (Windows XP), aucun problème ! Peut être que Windows XP
n'autorise pas les acquittements sélectifs, ce qui reviendrait au
comportement d'Ubuntu une fois tcp_sack passé à 0...
l'option sackOK dans le paquet SYN émis par Windows en début de connexion.
En tout cas mon Windows 2000 SP4 a bien l'option SACK activée, du moins
en IPv4 mais pas en IPv6 curieusement. Ça doit être réglable dans la
base de registre.
l'option sackOK dans le paquet SYN émis par Windows en début de connexion.
En tout cas mon Windows 2000 SP4 a bien l'option SACK activée, du moins
en IPv4 mais pas en IPv6 curieusement. Ça doit être réglable dans la
base de registre.
l'option sackOK dans le paquet SYN émis par Windows en début de connexion.
En tout cas mon Windows 2000 SP4 a bien l'option SACK activée, du moins
en IPv4 mais pas en IPv6 curieusement. Ça doit être réglable dans la
base de registre.
Pascal Hambourg a écrit :Facile à vérifier avec tcpdump, il suffit de vérifier la présence de
l'option sackOK dans le paquet SYN émis par Windows en début de
connexion.
Ah ben en fait si :
14:16:25.938980 IP moi.2224 > serveurmail.smtp: S
3865381750:3865381750(0) win 65535 <mss 1260,nop,wscale 2,nop,nop,sackOK>
Mais d'après ce que je lis ensuite, Windows envoie les segments dans
l'ordre et le serveur n'envoie jamais de SACK. Du coup, pas de problème
et l'envoi du mail s'effectue bien !
Pascal Hambourg a écrit :
Facile à vérifier avec tcpdump, il suffit de vérifier la présence de
l'option sackOK dans le paquet SYN émis par Windows en début de
connexion.
Ah ben en fait si :
14:16:25.938980 IP moi.2224 > serveurmail.smtp: S
3865381750:3865381750(0) win 65535 <mss 1260,nop,wscale 2,nop,nop,sackOK>
Mais d'après ce que je lis ensuite, Windows envoie les segments dans
l'ordre et le serveur n'envoie jamais de SACK. Du coup, pas de problème
et l'envoi du mail s'effectue bien !
Pascal Hambourg a écrit :Facile à vérifier avec tcpdump, il suffit de vérifier la présence de
l'option sackOK dans le paquet SYN émis par Windows en début de
connexion.
Ah ben en fait si :
14:16:25.938980 IP moi.2224 > serveurmail.smtp: S
3865381750:3865381750(0) win 65535 <mss 1260,nop,wscale 2,nop,nop,sackOK>
Mais d'après ce que je lis ensuite, Windows envoie les segments dans
l'ordre et le serveur n'envoie jamais de SACK. Du coup, pas de problème
et l'envoi du mail s'effectue bien !
Pascal Hambourg a écrit :Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif
via /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien
noyau <~ 2.6.20) ou
/proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1 (noyau récent).
Bingo !
J'ai directement essayé ça, et ça fonctionne !
Bravo pour avoir trouvé, et merci beaucoup !! Ça m'enlève une belle
épine du pied :)
Pascal Hambourg a écrit :
Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif
via /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien
noyau <~ 2.6.20) ou
/proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1 (noyau récent).
Bingo !
J'ai directement essayé ça, et ça fonctionne !
Bravo pour avoir trouvé, et merci beaucoup !! Ça m'enlève une belle
épine du pied :)
Pascal Hambourg a écrit :Un autre contournement possible (à vérifier) consisterait à régler le
suivi de connexion TCP sur la passerelle dans un mode plus permissif
via /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1 (ancien
noyau <~ 2.6.20) ou
/proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal=1 (noyau récent).
Bingo !
J'ai directement essayé ça, et ça fonctionne !
Bravo pour avoir trouvé, et merci beaucoup !! Ça m'enlève une belle
épine du pied :)
Que cela ne t'empêche pas de signaler le problème au service
informatique de l'école, traces à l'appui. Contourner c'est bien,
corriger c'est mieux. Je penche pour un firewall qui modifierait les
numéros de séquence TCP à la volée [1] mais oublierait ceux des SACK, ce
qui serait une honte dans la mesure où la spécification de SACK (RFC
2018) date de 1996. A la rigueur s'il s'avère que leur bazar n'est pas
fichu d'envoyer des SACK corrects, alors qu'ils les désactivent.
A noter qu'avec un noyau 2.6.25 et iptables 1.4.1 au moins, on peut
supprimer à la volée les options "SACK permitted" (dans les paquets SYN)
et "SACK" (dans les paquets d'acquittement) dans les paquets TCP qui
transitent par tun0 (pas besoin des deux à la fois normalement, c'est
ceinture et bretelles) :
iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
[1] Pourquoi modifier les numéros de séquence ? Certains systèmes ou
équipements généralement anciens générent des numéros de séquence
initiaux (ISN) trop facilement prévisibles, ce qui les rend vulnérables
à certaines attaques. J'imagine que le remplacement à la volée des
numéros de séquence initiaux par des valeurs moins prévisibles sert à
protéger contre ces attaques. Les ISN des systèmes modernes, autant
Linux que les Windows récents, sont très difficiles à prévoir.
Que cela ne t'empêche pas de signaler le problème au service
informatique de l'école, traces à l'appui. Contourner c'est bien,
corriger c'est mieux. Je penche pour un firewall qui modifierait les
numéros de séquence TCP à la volée [1] mais oublierait ceux des SACK, ce
qui serait une honte dans la mesure où la spécification de SACK (RFC
2018) date de 1996. A la rigueur s'il s'avère que leur bazar n'est pas
fichu d'envoyer des SACK corrects, alors qu'ils les désactivent.
A noter qu'avec un noyau 2.6.25 et iptables 1.4.1 au moins, on peut
supprimer à la volée les options "SACK permitted" (dans les paquets SYN)
et "SACK" (dans les paquets d'acquittement) dans les paquets TCP qui
transitent par tun0 (pas besoin des deux à la fois normalement, c'est
ceinture et bretelles) :
iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
[1] Pourquoi modifier les numéros de séquence ? Certains systèmes ou
équipements généralement anciens générent des numéros de séquence
initiaux (ISN) trop facilement prévisibles, ce qui les rend vulnérables
à certaines attaques. J'imagine que le remplacement à la volée des
numéros de séquence initiaux par des valeurs moins prévisibles sert à
protéger contre ces attaques. Les ISN des systèmes modernes, autant
Linux que les Windows récents, sont très difficiles à prévoir.
Que cela ne t'empêche pas de signaler le problème au service
informatique de l'école, traces à l'appui. Contourner c'est bien,
corriger c'est mieux. Je penche pour un firewall qui modifierait les
numéros de séquence TCP à la volée [1] mais oublierait ceux des SACK, ce
qui serait une honte dans la mesure où la spécification de SACK (RFC
2018) date de 1996. A la rigueur s'il s'avère que leur bazar n'est pas
fichu d'envoyer des SACK corrects, alors qu'ils les désactivent.
A noter qu'avec un noyau 2.6.25 et iptables 1.4.1 au moins, on peut
supprimer à la volée les options "SACK permitted" (dans les paquets SYN)
et "SACK" (dans les paquets d'acquittement) dans les paquets TCP qui
transitent par tun0 (pas besoin des deux à la fois normalement, c'est
ceinture et bretelles) :
iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
[1] Pourquoi modifier les numéros de séquence ? Certains systèmes ou
équipements généralement anciens générent des numéros de séquence
initiaux (ISN) trop facilement prévisibles, ce qui les rend vulnérables
à certaines attaques. J'imagine que le remplacement à la volée des
numéros de séquence initiaux par des valeurs moins prévisibles sert à
protéger contre ces attaques. Les ISN des systèmes modernes, autant
Linux que les Windows récents, sont très difficiles à prévoir.
Pascal Hambourg a écrit :iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
Et donc ceci supprimerait l'option sackOK dans les paquets SYN en début
de connexion/dans les paquets d'acquittement, ce qui reviendrait à
mettre tcp_sack à 0 sur les clients mais sans avoir à le faire sur tous
les clients ?
Vous m'impressionnez, vous êtes admin réseau de profession ? :)
Pascal Hambourg a écrit :
iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
Et donc ceci supprimerait l'option sackOK dans les paquets SYN en début
de connexion/dans les paquets d'acquittement, ce qui reviendrait à
mettre tcp_sack à 0 sur les clients mais sans avoir à le faire sur tous
les clients ?
Vous m'impressionnez, vous êtes admin réseau de profession ? :)
Pascal Hambourg a écrit :iptables -t mangle -A POSTROUTING -o tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
iptables -t mangle -A PREROUTING -i tun0 -p tcp
-j TCPOPTSTRIP --strip-options sack-permitted,sack
Et donc ceci supprimerait l'option sackOK dans les paquets SYN en début
de connexion/dans les paquets d'acquittement, ce qui reviendrait à
mettre tcp_sack à 0 sur les clients mais sans avoir à le faire sur tous
les clients ?
Vous m'impressionnez, vous êtes admin réseau de profession ? :)