[OpenBSD] Firewall et problème de transfert sur des gros fichiers
4 réponses
Christophe Labouisse
J'ai un problème assez récurent lorsque j'essaye de récupérer depuis
l'extérieur des fichiers stocké chez moi par scp. J'ai une machine Nunux
qui est sur un LAN protégé par un firewall sous OpenBSD avec pf. De
l'extérieur je fais : "scp chezmoi:/fichier .". Tout marche bien au
départ mais lorsque la taille du fichier est suffisamment importante le
transfert s'arrête (scp indique "stalled" en vitesse de transfert) &
reste ainsi jusqu'à temps que je l'interrompe pas un Ctrl-C rageur.
N'ayant pas d'info dans les logs j'ai décidé lancé deux tcpdump, un sur
l'interface réseau interne (xl0) & un sur l'interface réseau externe
(tun0). Lorsque je compare le deux tout va bien jusqu'à ce que je vois
les lignes suivantes dans le tcpdump de tun0 :
Bref pour une raison inconnue, le pf a arrêté de transmettre les paquets
d'ailleurs vers chez moi à partir de celui de 11:27:13.671686. Est-ce que
quelqu'un a une piste à explorer ?
Christophe
--
Le cinéma en Lumière : http://www.lumiere.org/
Retirer .invalid pour me répondre
Remove .invalid to reply
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
Est-ce que ton `chez.moi' a une adresse fixe ? Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ? Je crois qu'avec les bonnes incantations style (tun0) a la place de tun0, pf est capable de s'en sortir.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou c'est toute connexion a longue duree ?
Pour contourner vaguement le probleme, rsync sait reprendre des transferts interrompus de la sorte... et l'option -B s'avere alors particulierement utile.
En rapport avec la reponse de Xavier:
When a packet matches a stateful connection, the seconds to live for the connection will be updated to that of the proto.modifier which corresponds to the connection state. Each packet which matches this state will reset the TTL. Tuning these values may im- prove the performance of the firewall at the risk of dropping valid idle connections.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey, par hasard).
Est-ce que ton `chez.moi' a une adresse fixe ?
Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ?
Je crois qu'avec les bonnes incantations style (tun0) a la place de tun0,
pf est capable de s'en sortir.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou
c'est toute connexion a longue duree ?
Pour contourner vaguement le probleme, rsync sait reprendre des transferts
interrompus de la sorte... et l'option -B s'avere alors particulierement
utile.
En rapport avec la reponse de Xavier:
When a packet matches a stateful connection, the seconds to live
for the connection will be updated to that of the proto.modifier
which corresponds to the connection state. Each packet which
matches this state will reset the TTL. Tuning these values may im-
prove the performance of the firewall at the risk of dropping valid
idle connections.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le
firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne
capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey, par
hasard).
Est-ce que ton `chez.moi' a une adresse fixe ? Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ? Je crois qu'avec les bonnes incantations style (tun0) a la place de tun0, pf est capable de s'en sortir.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou c'est toute connexion a longue duree ?
Pour contourner vaguement le probleme, rsync sait reprendre des transferts interrompus de la sorte... et l'option -B s'avere alors particulierement utile.
En rapport avec la reponse de Xavier:
When a packet matches a stateful connection, the seconds to live for the connection will be updated to that of the proto.modifier which corresponds to the connection state. Each packet which matches this state will reset the TTL. Tuning these values may im- prove the performance of the firewall at the risk of dropping valid idle connections.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey, par hasard).
Christophe Labouisse
On Sun, 02 Jan 2005 23:59:21 +0000, Marc Espie wrote :
Est-ce que ton `chez.moi' a une adresse fixe ? Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ?
chez.moi est effectivement une adresse IP fixe mais je n'ai pas souvenir d'un changement intempestif d'adresse IP depuis que je suis en IP fixe. En outre je n'ai ce problème que sur le transfert : la connexion ssh en cours n'est pas affectée.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou c'est toute connexion a longue duree ?
Non uniquement sur les gros transferts scp, pas de problème pour maintenir une connexion ssh ouverte plusieurs heures ni tunneller sur imap via cette même connexion.
Pour contourner vaguement le probleme, rsync sait reprendre des transferts interrompus de la sorte... et l'option -B s'avere alors particulierement utile.
En fait j'ai trouvé un contournement qui consiste à initier le scp à partir de chez moi plutôt que l'inverse.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey, par hasard).
Non non je viens de refaire plusieurs fois le test alors que le trafic réseau chez moi est réduit à un serveur mail perso (donc pas grand chose), la récupération des news & une connexion ssh. À part ça rien de particulièrement consommateur en paquets (à moins que mon firewall ne croule sous les scans & les tentatives de connexion netbios).
On Sun, 02 Jan 2005 23:59:21 +0000, Marc Espie wrote :
Est-ce que ton `chez.moi' a une adresse fixe ?
Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ?
chez.moi est effectivement une adresse IP fixe mais je n'ai pas souvenir
d'un changement intempestif d'adresse IP depuis que je suis en IP fixe. En
outre je n'ai ce problème que sur le transfert : la connexion ssh en
cours n'est pas affectée.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou
c'est toute connexion a longue duree ?
Non uniquement sur les gros transferts scp, pas de problème pour
maintenir une connexion ssh ouverte plusieurs heures ni tunneller sur imap
via cette même connexion.
Pour contourner vaguement le probleme, rsync sait reprendre des
transferts interrompus de la sorte... et l'option -B s'avere alors
particulierement utile.
En fait j'ai trouvé un contournement qui consiste à initier le scp à
partir de chez moi plutôt que l'inverse.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le
firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne
capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey,
par hasard).
Non non je viens de refaire plusieurs fois le test alors que le trafic
réseau chez moi est réduit à un serveur mail perso (donc pas grand
chose), la récupération des news & une connexion ssh. À part ça rien
de particulièrement consommateur en paquets (à moins que mon firewall ne
croule sous les scans & les tentatives de connexion netbios).
On Sun, 02 Jan 2005 23:59:21 +0000, Marc Espie wrote :
Est-ce que ton `chez.moi' a une adresse fixe ? Ca serait pas un gag de reconfiguration de ppp qui te change l'adresse IP ?
chez.moi est effectivement une adresse IP fixe mais je n'ai pas souvenir d'un changement intempestif d'adresse IP depuis que je suis en IP fixe. En outre je n'ai ce problème que sur le transfert : la connexion ssh en cours n'est pas affectée.
Plus generalement, c'est uniquement les gros transferts a base de scp, ou c'est toute connexion a longue duree ?
Non uniquement sur les gros transferts scp, pas de problème pour maintenir une connexion ssh ouverte plusieurs heures ni tunneller sur imap via cette même connexion.
Pour contourner vaguement le probleme, rsync sait reprendre des transferts interrompus de la sorte... et l'option -B s'avere alors particulierement utile.
En fait j'ai trouvé un contournement qui consiste à initier le scp à partir de chez moi plutôt que l'inverse.
sauf si les regles de pf sont explicitement stateless, je ne vois pas le firewall dropper les connexions, sauf s'il est vraiment charge.
Je pencherais plutot pour un changement dynamique d'adresse IP que pf ne capte pas...
(dis, t'as pas de trucs hyper-gourmands en paquets comme un mldonkey, par hasard).
Non non je viens de refaire plusieurs fois le test alors que le trafic réseau chez moi est réduit à un serveur mail perso (donc pas grand chose), la récupération des news & une connexion ssh. À part ça rien de particulièrement consommateur en paquets (à moins que mon firewall ne croule sous les scans & les tentatives de connexion netbios).
Christophe Labouisse
On Sun, 02 Jan 2005 14:40:32 +0100, Xavier wrote :
Probablement que la connexion TCP a expiré dans la table des états. Je ne connais pas le paramètre qui définit ça, mais à mon avis tu peux chercher de ce côté.
Je viens de reproduire ce problème en faisant des pfctl -s state durant le transfert. Je vois bien une connexion arriver sur le port 22 lorsque je lance le transfert mais lorsqu'il s'arrête cette connexion est toujours présent en ESTABLISHED:ESTABLISHED (d'ailleurs elle reste même lorsque j'ai fait un ctrl-c pour arrêter le transfert).
On Sun, 02 Jan 2005 14:40:32 +0100, Xavier wrote :
Probablement que la connexion TCP a expiré dans la table des états. Je
ne connais pas le paramètre qui définit ça, mais à mon avis tu peux
chercher de ce côté.
Je viens de reproduire ce problème en faisant des pfctl -s state durant
le transfert. Je vois bien une connexion arriver sur le port 22 lorsque je
lance le transfert mais lorsqu'il s'arrête cette connexion est toujours
présent en ESTABLISHED:ESTABLISHED (d'ailleurs elle reste même lorsque
j'ai fait un ctrl-c pour arrêter le transfert).
On Sun, 02 Jan 2005 14:40:32 +0100, Xavier wrote :
Probablement que la connexion TCP a expiré dans la table des états. Je ne connais pas le paramètre qui définit ça, mais à mon avis tu peux chercher de ce côté.
Je viens de reproduire ce problème en faisant des pfctl -s state durant le transfert. Je vois bien une connexion arriver sur le port 22 lorsque je lance le transfert mais lorsqu'il s'arrête cette connexion est toujours présent en ESTABLISHED:ESTABLISHED (d'ailleurs elle reste même lorsque j'ai fait un ctrl-c pour arrêter le transfert).
J.
Christophe Labouisse wrote:
J'ai un problème assez récurent lorsque j'essaye de récupérer depuis l'extérieur des fichiers stocké chez moi par scp. J'ai une machine Nunux qui est sur un LAN protégé par un firewall sous OpenBSD avec pf. De l'extérieur je fais : "scp chezmoi:/fichier .". Tout marche bien au départ mais lorsque la taille du fichier est suffisamment importante le transfert s'arrête (scp indique "stalled" en vitesse de transfert) & reste ainsi jusqu'à temps que je l'interrompe pas un Ctrl-C rageur.
Cela se produit souvent quand il y a un problème de negotiation de duplex sur les réseaux ethernet. Ta configuration réseau entre ton linux et ton bsd est peut-être mauvaise (100FX d'un coté vs 100HX de l'autre par exemple).
J.
Christophe Labouisse wrote:
J'ai un problème assez récurent lorsque j'essaye de récupérer depuis
l'extérieur des fichiers stocké chez moi par scp. J'ai une machine Nunux
qui est sur un LAN protégé par un firewall sous OpenBSD avec pf. De
l'extérieur je fais : "scp chezmoi:/fichier .". Tout marche bien au
départ mais lorsque la taille du fichier est suffisamment importante le
transfert s'arrête (scp indique "stalled" en vitesse de transfert) &
reste ainsi jusqu'à temps que je l'interrompe pas un Ctrl-C rageur.
Cela se produit souvent quand il y a un problème de negotiation de
duplex sur les réseaux ethernet. Ta configuration réseau entre ton linux
et ton bsd est peut-être mauvaise (100FX d'un coté vs 100HX de l'autre
par exemple).
J'ai un problème assez récurent lorsque j'essaye de récupérer depuis l'extérieur des fichiers stocké chez moi par scp. J'ai une machine Nunux qui est sur un LAN protégé par un firewall sous OpenBSD avec pf. De l'extérieur je fais : "scp chezmoi:/fichier .". Tout marche bien au départ mais lorsque la taille du fichier est suffisamment importante le transfert s'arrête (scp indique "stalled" en vitesse de transfert) & reste ainsi jusqu'à temps que je l'interrompe pas un Ctrl-C rageur.
Cela se produit souvent quand il y a un problème de negotiation de duplex sur les réseaux ethernet. Ta configuration réseau entre ton linux et ton bsd est peut-être mauvaise (100FX d'un coté vs 100HX de l'autre par exemple).
