Absolument pas, ma box laisse tout passer, sans que j'ai eu à configurer quoi que ce soit, et c'était le cas de tous les FAI quand la box n'est pas configuré en NAT, à moins d'un changement récent.
Parce que la configuration par défaut (sans NAT) c'est un bridge, et que filtrer quand tu bridges c'est pas super propre, et que le but du bridge, justement, est en général de laisser une autre machine derrière le bridge filtrer elle-même.
Comme dit précédemment, et il semblerai que l'on se soit pas en accord la dessus, ce n'est pas le cas en ipv4, ce n'est pas le cas, en ce moment en ipv6, je ne vois absolument pas pourquoi ça changerai
Parce qu'en IPv4 actuellement, sans NAT, tu bridges (enfin, ta box), alors qu'en IPv6, tu vas router, ce qui n'est pas pareil, et les cas d'usage sont différents, et donc (c'est mon avis) la configuration par défaut aussi.
Free n'est peut-être pas encore décidé là-dessus. Moi je pense aussi qu'ils n'ont pas encore mis les moyen pour pousser la connectivité IPv6 jusqu'au bout, et qu'à défaut d'avoir une interface web pour configurer le firewall de la freebox en v6, ils ne filtrent rien. C'est tout le problème de ne pas avoir la maîtrise du « CPE », comme on dit.
ah oui c'est clair que faire un ssh user@rubicon ... /bin/su ; iptables ... c'est plus simple... (en plus de devoir taper un mot de passe root)
Je dirais que tu te poses les mauvaises questions. Si c'est pour une redirection temporaire, c'est que c'est donc pour accéder à certains services de ton réseau ? Monte alors un VPN. Ça tombe bien, IPSEC est fait pour ça : filtre les connexions entrantes de ton réseau, mais tout ce qui arrive par IPSEC passera. Ainsi, quand tu as la « clé » de ton réseau, toutes tes machines deviennent « visibles », ou plutôt atteignables. Et tout ça en gardant le même adressage que tu sois à l'intérieur ou à l'extérieur !
mais SSH marche très bien pour faire mes tests...
Au pire, tu peux toujours faire un SSH sur la machine directement (en laissant passer le SSH depuis l'extérieur pour toutes les machines), mais dans la limite où le service que tu veux atteindre est accessible en SSH ; ça gène un peu pour les machines Windows, effectivement.
En fait, faire du v6, c'est à dire de l'IP routé, c'est une vision vraiment différente du NAT ; il faut revoir un peu sa manière de penser.
Mais par défaut, quand je configure un nat, les machine derrière ne sont pas accessible, alors oui par défaut un firewall ne fait pas de nat, mais à partir du moment où tu as ajouté la règle magique ainsi que le echo 1 > /proc/net/.../ip_forward tu es en nat, et a moins de rajouter une règle à la con, les machine derrières ne sont pas accessible.
Encore une fois, une règle aussi en IPv6 pour que les machines derrière ne soient pas accessible. Je ne vois pas la différence.
Le fait que ce soit ou non un firewall derrière je m'en fout, (enfin moi non), ce que je veux c'est pas un firewall, c'est que les machine derrière puisse accéder à internet que ce soit ipv421 ip666 ou ip111 c'est le cadet de mes soucis. La limitation d'adresse ipv4 force un NAT; que ce NAT soit fait sur un firewall n'est pas l'important.
Si demain y a plus besoin de nat, le firewall imposé par le nat disparaîtra chez un paquet de gens.
Je pense que la conf par défaut des FAI qui feront « bien » leur boulot, ce sera de bloquer les connexions entrantes. Actuellement, c'est surtout les geeks qui s'y sont intéressés, donc au contraire un blocage par défaut aurait sûrement provoqué un tollé. Je pense qu'avec la maturité du l'offre, on va voir certains paramètres par défaut changer.
Et juste pour relancer une petite pique, si les gens avaient plus le choix dans le matériel qu'ils utilisent pour accéder à leur FAI (leur box, quoi), peut-être que certains se seraient plus vite bougé le cul en voyant les clients qui gueulent.
Sous linux oui c'est iptables qui s'en charge; sous windows ça ne l'est sûrement pas.
Je pense que c'est la stack réseau niveau kernel, comme linux. iptables ne veut pas dire « firewall », comme son nom l'indique : il manipule la gestion des paquets au niveau du kernel. Que ce soit pour filtrer le trafic, ce qu'on appelle couramment « firewall », ou pour faire du NAT, ou pour faire de la QoS, ou pour faire quoi que ce soit d'autre.
[^] # Re: Pas forcément la fin du NAT
Posté par benoar . En réponse au journal IPcalypse : J - 42. Évalué à 2.
Parce que la configuration par défaut (sans NAT) c'est un bridge, et que filtrer quand tu bridges c'est pas super propre, et que le but du bridge, justement, est en général de laisser une autre machine derrière le bridge filtrer elle-même.
Comme dit précédemment, et il semblerai que l'on se soit pas en accord la dessus, ce n'est pas le cas en ipv4, ce n'est pas le cas, en ce moment en ipv6, je ne vois absolument pas pourquoi ça changerai
Parce qu'en IPv4 actuellement, sans NAT, tu bridges (enfin, ta box), alors qu'en IPv6, tu vas router, ce qui n'est pas pareil, et les cas d'usage sont différents, et donc (c'est mon avis) la configuration par défaut aussi.
tiens si mon expérience personnelle ne te suffit pas en voila un autre qui a fait le même constat
http://blog.koreus.com/freebox-routeur-ipv6/
Free n'est peut-être pas encore décidé là-dessus. Moi je pense aussi qu'ils n'ont pas encore mis les moyen pour pousser la connectivité IPv6 jusqu'au bout, et qu'à défaut d'avoir une interface web pour configurer le firewall de la freebox en v6, ils ne filtrent rien. C'est tout le problème de ne pas avoir la maîtrise du « CPE », comme on dit.
ah oui c'est clair que faire un ssh user@rubicon ... /bin/su ; iptables ... c'est plus simple... (en plus de devoir taper un mot de passe root)
Je dirais que tu te poses les mauvaises questions. Si c'est pour une redirection temporaire, c'est que c'est donc pour accéder à certains services de ton réseau ? Monte alors un VPN. Ça tombe bien, IPSEC est fait pour ça : filtre les connexions entrantes de ton réseau, mais tout ce qui arrive par IPSEC passera. Ainsi, quand tu as la « clé » de ton réseau, toutes tes machines deviennent « visibles », ou plutôt atteignables. Et tout ça en gardant le même adressage que tu sois à l'intérieur ou à l'extérieur !
mais SSH marche très bien pour faire mes tests...
Au pire, tu peux toujours faire un SSH sur la machine directement (en laissant passer le SSH depuis l'extérieur pour toutes les machines), mais dans la limite où le service que tu veux atteindre est accessible en SSH ; ça gène un peu pour les machines Windows, effectivement.
En fait, faire du v6, c'est à dire de l'IP routé, c'est une vision vraiment différente du NAT ; il faut revoir un peu sa manière de penser.
Mais par défaut, quand je configure un nat, les machine derrière ne sont pas accessible, alors oui par défaut un firewall ne fait pas de nat, mais à partir du moment où tu as ajouté la règle magique ainsi que le echo 1 > /proc/net/.../ip_forward tu es en nat, et a moins de rajouter une règle à la con, les machine derrières ne sont pas accessible.
Encore une fois, une règle aussi en IPv6 pour que les machines derrière ne soient pas accessible. Je ne vois pas la différence.
Le fait que ce soit ou non un firewall derrière je m'en fout, (enfin moi non), ce que je veux c'est pas un firewall, c'est que les machine derrière puisse accéder à internet que ce soit ipv421 ip666 ou ip111 c'est le cadet de mes soucis. La limitation d'adresse ipv4 force un NAT; que ce NAT soit fait sur un firewall n'est pas l'important.
Si demain y a plus besoin de nat, le firewall imposé par le nat disparaîtra chez un paquet de gens.
Je pense que la conf par défaut des FAI qui feront « bien » leur boulot, ce sera de bloquer les connexions entrantes. Actuellement, c'est surtout les geeks qui s'y sont intéressés, donc au contraire un blocage par défaut aurait sûrement provoqué un tollé. Je pense qu'avec la maturité du l'offre, on va voir certains paramètres par défaut changer.
Et juste pour relancer une petite pique, si les gens avaient plus le choix dans le matériel qu'ils utilisent pour accéder à leur FAI (leur box, quoi), peut-être que certains se seraient plus vite bougé le cul en voyant les clients qui gueulent.
Sous linux oui c'est iptables qui s'en charge; sous windows ça ne l'est sûrement pas.
Je pense que c'est la stack réseau niveau kernel, comme linux. iptables ne veut pas dire « firewall », comme son nom l'indique : il manipule la gestion des paquets au niveau du kernel. Que ce soit pour filtrer le trafic, ce qu'on appelle couramment « firewall », ou pour faire du NAT, ou pour faire de la QoS, ou pour faire quoi que ce soit d'autre.