J'essaie de contraindre mon routeur IPv6 (Linux) à router
correctement du ftp passif. J'en profite, j'ai enfin réussi à
stabiliser IPv6 (après avoir bataillé avec ZyXEL et obtenu deux
firmares correctifs, le dernier semblant ne plus faire de choses
bizarres). Je n'ai rien trouvé de pertinent jusqu'à
aujourd'hui et j'ai dû rajouter :
ip6tables -PFORWARD ACCEPT
ce qui n'est pas du plus bel effet.
En IPv4, il existe un module pour tracker les ports FTP au travers
du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Toute idée sera la bienvenue.
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
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
Pascal Hambourg
Bonjour, Le 03/06/2016 11:02, JKB a écrit :
J'essaie de contraindre mon routeur IPv6 (Linux) à router correctement du ftp passif.
Comment ça, "router" ? Le routage de base des paquets IP se fiche que les paquets appartiennent à une connexion de données FTP passive.
j'ai dû rajouter : ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage, il fait tout au plus des transformations qui peuvent affecter le routage de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour supporter le NAT IPv6 stateful).
Bonjour,
Le 03/06/2016 11:02, JKB a écrit :
J'essaie de contraindre mon routeur IPv6 (Linux) à router
correctement du ftp passif.
Comment ça, "router" ?
Le routage de base des paquets IP se fiche que les paquets appartiennent
à une connexion de données FTP passive.
j'ai dû rajouter :
ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage,
il fait tout au plus des transformations qui peuvent affecter le routage
de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers
du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et
nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en
IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour
supporter le NAT IPv6 stateful).
J'essaie de contraindre mon routeur IPv6 (Linux) à router correctement du ftp passif.
Comment ça, "router" ? Le routage de base des paquets IP se fiche que les paquets appartiennent à une connexion de données FTP passive.
j'ai dû rajouter : ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage, il fait tout au plus des transformations qui peuvent affecter le routage de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour supporter le NAT IPv6 stateful).
JKB
Le Fri, 3 Jun 2016 20:14:34 +0200, Pascal Hambourg écrivait :
Bonjour, Le 03/06/2016 11:02, JKB a écrit :
J'essaie de contraindre mon routeur IPv6 (Linux) à router correctement du ftp passif.
Comment ça, "router" ? Le routage de base des paquets IP se fiche que les paquets appartiennent à une connexion de données FTP passive.
IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue. Il arrive aussi que des transactions https subissent le même sort. Or à l'instant où le ftp échoue, la connextion IPv6 est parfaitement active et je peux faire un ftp sur le même fichier en IPv4 sans problème.
j'ai dû rajouter : ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage, il fait tout au plus des transformations qui peuvent affecter le routage de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour supporter le NAT IPv6 stateful).
Le Fri, 3 Jun 2016 20:14:34 +0200,
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Bonjour,
Le 03/06/2016 11:02, JKB a écrit :
J'essaie de contraindre mon routeur IPv6 (Linux) à router
correctement du ftp passif.
Comment ça, "router" ?
Le routage de base des paquets IP se fiche que les paquets appartiennent
à une connexion de données FTP passive.
IPv6 internet ----- passerelle routeur ----- LAN
| | |
VPNs
Depuis le LAN, certains paquets se perdent quelque part. En
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir
une connexion, passer d'un répertoire à un autre, mais le transfert
de données échoue. Il arrive aussi que des transactions https
subissent le même sort. Or à l'instant où le ftp échoue, la connextion
IPv6 est parfaitement active et je peux faire un ftp sur le même
fichier en IPv4 sans problème.
j'ai dû rajouter :
ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage,
il fait tout au plus des transformations qui peuvent affecter le routage
de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers
du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et
nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en
IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour
supporter le NAT IPv6 stateful).
Visiblement, avec un 4.3, ça ne fonctionne pas. Je connais ces
modules et ils sont bien chargés.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 3 Jun 2016 20:14:34 +0200, Pascal Hambourg écrivait :
Bonjour, Le 03/06/2016 11:02, JKB a écrit :
J'essaie de contraindre mon routeur IPv6 (Linux) à router correctement du ftp passif.
Comment ça, "router" ? Le routage de base des paquets IP se fiche que les paquets appartiennent à une connexion de données FTP passive.
IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue. Il arrive aussi que des transactions https subissent le même sort. Or à l'instant où le ftp échoue, la connextion IPv6 est parfaitement active et je peux faire un ftp sur le même fichier en IPv4 sans problème.
j'ai dû rajouter : ip6tables -P FORWARD ACCEPT
C'est du filtrage, pas du routage. Ip{6}tables ne fait pas de routage, il fait tout au plus des transformations qui peuvent affecter le routage de base (NAT) ou avancé (MARK).
En IPv4, il existe un module pour tracker les ports FTP au travers du NAT. Pour IPv6, j'avoue ne pas savoir comment faire proprement.
Il existe deux modules : nf_conntrack_ftp pour le suivi de connexion, et nf_nat_ftp pour le NAT. Que je sache, ils fonctionnent aussi bien en IPv6 qu'en IPv4 (pour le second, avec un noyau suffisamment récent pour supporter le NAT IPv6 stateful).
Le Fri, 3 Jun 2016 20:14:34 +0200, IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de transfert ? Le listage de répertoire, qui utilise aussi une connexion de données, fonctionne-t-il ? Le FTP actif fonctionne mieux ?
JKB a écrit :
Le Fri, 3 Jun 2016 20:14:34 +0200,
IPv6 internet ----- passerelle routeur ----- LAN
| | |
VPNs
Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de
règles ip6tables en place ? Autrement le changement de la politique par
défaut de FORWARD n'aurait pas eu d'effet.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir
une connexion, passer d'un répertoire à un autre, mais le transfert
de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de
transfert ?
Le listage de répertoire, qui utilise aussi une connexion de données,
fonctionne-t-il ?
Le FTP actif fonctionne mieux ?
Le Fri, 3 Jun 2016 20:14:34 +0200, IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de transfert ? Le listage de répertoire, qui utilise aussi une connexion de données, fonctionne-t-il ? Le FTP actif fonctionne mieux ?
JKB
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Le Fri, 3 Jun 2016 20:14:34 +0200, IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de transfert ?
J'arrive à changer de répertoire, mais ni à faire un ls ni un get. En fait, les symptomes sont assez conforme à ce qui se passerait en IPv4 sans le module NAT ftp du noyau Linux.
Le listage de répertoire, qui utilise aussi une connexion de données, fonctionne-t-il ?
Le Wed, 08 Jun 2016 21:56:38 +0200,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Le Fri, 3 Jun 2016 20:14:34 +0200,
IPv6 internet ----- passerelle routeur ----- LAN
| | |
VPNs
Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de
règles ip6tables en place ? Autrement le changement de la politique par
défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma
machine cliente et plus rien ne répond en face.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir
une connexion, passer d'un répertoire à un autre, mais le transfert
de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de
transfert ?
J'arrive à changer de répertoire, mais ni à faire un ls ni un get.
En fait, les symptomes sont assez conforme à ce qui se passerait en
IPv4 sans le module NAT ftp du noyau Linux.
Le listage de répertoire, qui utilise aussi une connexion de données,
fonctionne-t-il ?
Non.
Le FTP actif fonctionne mieux ?
Je ne sais pas, je n'ai pas eu l'occasion de tester plus avant.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Le Fri, 3 Jun 2016 20:14:34 +0200, IPv6 internet ----- passerelle routeur ----- LAN | | | VPNs Depuis le LAN, certains paquets se perdent quelque part. En
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
particulier les paquets de FTP passifs. Typiquement, je peux ouvrir une connexion, passer d'un répertoire à un autre, mais le transfert de données échoue.
Dès le début (impossible de compléter le 3-way handshake) ou en cours de transfert ?
J'arrive à changer de répertoire, mais ni à faire un ls ni un get. En fait, les symptomes sont assez conforme à ce qui se passerait en IPv4 sans le module NAT ftp du noyau Linux.
Le listage de répertoire, qui utilise aussi une connexion de données, fonctionne-t-il ?
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se perdent quelque part". Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ? Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ? Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Le 09/06/2016 00:09, JKB a écrit :
Le Wed, 08 Jun 2016 21:56:38 +0200,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de
règles ip6tables en place ? Autrement le changement de la politique par
défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma
machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se
perdent quelque part".
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Les paquets de réponse destinés au client, tu les vois entrer dans le
routeur ?
Si la réponse est oui à la premier question et non à la seconde, ce
n'est pas le routeur qui bloque. Dans le cas contraire, le routeur
fait-il du filtrage avec ip6tables ?
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se perdent quelque part". Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ? Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ? Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
JKB
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Le 09/06/2016 00:09, JKB a écrit :
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se perdent quelque part". Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Le Thu, 9 Jun 2016 20:22:31 +0200,
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 09/06/2016 00:09, JKB a écrit :
Le Wed, 08 Jun 2016 21:56:38 +0200,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de
règles ip6tables en place ? Autrement le changement de la politique par
défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma
machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se
perdent quelque part".
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Les paquets de réponse destinés au client, tu les vois entrer dans le
routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Si la réponse est oui à la premier question et non à la seconde, ce
n'est pas le routeur qui bloque. Dans le cas contraire, le routeur
fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Le 09/06/2016 00:09, JKB a écrit :
Le Wed, 08 Jun 2016 21:56:38 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Depuis le LAN, certains paquets se perdent quelque part.
Par "se perdent", tu veux bien dire qu'ils sont bloqués par le jeu de règles ip6tables en place ? Autrement le changement de la politique par défaut de FORWARD n'aurait pas eu d'effet.
Par se perdent j'entends que je vois passer des paquets issus de ma machine cliente et plus rien ne répond en face.
Ce n'est pas la même chose que "Depuis le LAN, certains paquets se perdent quelque part". Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le client qui a l'initiative d'établir la connexion de données en envoyant le premier paquet SYN, qui ressemble donc à n'importe quelle connexion TCP sortante mais utilise juste un port de destination quelconque au lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ? Cela affecte-t-il à la fois l'upload et le download ? Il y a quelque chose entre le routeur et le modem à part éventuellement un switch et des câbles ? Le client utilise-t-il la même adresse IPv6 source que pour la connexion de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a plusieurs adresses IP.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Et ça coince quand même, si je comprends bien ?
JKB a écrit :
Le Thu, 9 Jun 2016 20:22:31 +0200,
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le
client qui a l'initiative d'établir la connexion de données en envoyant
le premier paquet SYN, qui ressemble donc à n'importe quelle connexion
TCP sortante mais utilise juste un port de destination quelconque au
lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le
routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ?
Cela affecte-t-il à la fois l'upload et le download ?
Il y a quelque chose entre le routeur et le modem à part éventuellement
un switch et des câbles ?
Le client utilise-t-il la même adresse IPv6 source que pour la connexion
de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a
plusieurs adresses IP.
Si la réponse est oui à la premier question et non à la seconde, ce
n'est pas le routeur qui bloque. Dans le cas contraire, le routeur
fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le client qui a l'initiative d'établir la connexion de données en envoyant le premier paquet SYN, qui ressemble donc à n'importe quelle connexion TCP sortante mais utilise juste un port de destination quelconque au lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ? Cela affecte-t-il à la fois l'upload et le download ? Il y a quelque chose entre le routeur et le modem à part éventuellement un switch et des câbles ? Le client utilise-t-il la même adresse IPv6 source que pour la connexion de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a plusieurs adresses IP.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Et ça coince quand même, si je comprends bien ?
JKB
Le Fri, 10 Jun 2016 20:29:36 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le client qui a l'initiative d'établir la connexion de données en envoyant le premier paquet SYN, qui ressemble donc à n'importe quelle connexion TCP sortante mais utilise juste un port de destination quelconque au lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ?
Même pas.
Cela affecte-t-il à la fois l'upload et le download ?
Je n'ai testé que le download.
Il y a quelque chose entre le routeur et le modem à part éventuellement un switch et des câbles ?
Strictement rien.
Le client utilise-t-il la même adresse IPv6 source que pour la connexion de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a plusieurs adresses IP.
Oui, exactement la même en 2001:xx.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Le Fri, 10 Jun 2016 20:29:36 +0200,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Le Thu, 9 Jun 2016 20:22:31 +0200,
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le
client qui a l'initiative d'établir la connexion de données en envoyant
le premier paquet SYN, qui ressemble donc à n'importe quelle connexion
TCP sortante mais utilise juste un port de destination quelconque au
lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le
routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ?
Même pas.
Cela affecte-t-il à la fois l'upload et le download ?
Je n'ai testé que le download.
Il y a quelque chose entre le routeur et le modem à part éventuellement
un switch et des câbles ?
Strictement rien.
Le client utilise-t-il la même adresse IPv6 source que pour la connexion
de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a
plusieurs adresses IP.
Oui, exactement la même en 2001:xx.
Si la réponse est oui à la premier question et non à la seconde, ce
n'est pas le routeur qui bloque. Dans le cas contraire, le routeur
fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
Et ça coince quand même, si je comprends bien ?
Exactement.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 10 Jun 2016 20:29:36 +0200, Pascal Hambourg écrivait :
JKB a écrit :
Le Thu, 9 Jun 2016 20:22:31 +0200, Pascal Hambourg écrivait :
Les paquets émis par ta machine cliente, tu les vois ressortir du routeur ?
Oui.
Donc le routeur ne les bloque/perd pas. En mode passif FTP, c'est le client qui a l'initiative d'établir la connexion de données en envoyant le premier paquet SYN, qui ressemble donc à n'importe quelle connexion TCP sortante mais utilise juste un port de destination quelconque au lieu d'un port connu.
Les paquets de réponse destinés au client, tu les vois entrer dans le routeur ?
Non. Remarque, je ne les vois pas non plus ressortir du modem.
Même pas le premier paquet de réponse SYN/ACK ?
Même pas.
Cela affecte-t-il à la fois l'upload et le download ?
Je n'ai testé que le download.
Il y a quelque chose entre le routeur et le modem à part éventuellement un switch et des câbles ?
Strictement rien.
Le client utilise-t-il la même adresse IPv6 source que pour la connexion de commande ? Il y a parfois des comportements bizarres lorsqu'un hôte a plusieurs adresses IP.
Oui, exactement la même en 2001:xx.
Si la réponse est oui à la premier question et non à la seconde, ce n'est pas le routeur qui bloque. Dans le cas contraire, le routeur fait-il du filtrage avec ip6tables ?
Pour mes tests, j'ai tout ouvert sur la règle FORWARD.
