benoar a écrit 4238 commentaires

Bon, désolé pour le ton qui a pu paraître un peu "énervé", c'est juste que ton histoire et étrange et je continue à ne pas comprendre la moitié des choses. En plus, aller chez un "client" à titre "non professionnel", je trouve ça encore plus étrange, mais tu dois avoir tes raisons ...

En tous cas c'est cool que tu aies envie d'apprendre, mais pour l'instant je laisse tomber le problème ,je n'arrive pas à comprendre : j'avoue que même tes phrases sont pour moi parfois incompréhensibles, en dehors de l'aspect technique (français, logique).

Si t'avances et que tu as plus de détails à peu près bien présentés, rangés et expliqués, n'hésites pas. Bon courage.

Ta route par défaut indique que la passerelle par défaut est 0.0.0.0 .... forcément, tes paquets ne vont pas aller loin. Je suppose que c'est 10.64.64.64 (en espérant qu'elle est up, peut-être bloque-t-elle juste les pings ?) il faut effacer la route par défaut et faire :
ip route add default via 10.64.64.64 dev ppp0

J'ai juste "vu" parfois, sur leurs sites, des logos de ces entreprises. Je ne sais pas du tout quelles sont leurs relations avec eux. Je sais qu'on peut trouver Ninja & Sonar dans les grandes enseignes, Brownswood c'est un peu moins sûr. Mais on va dire qu'ils font ça parce que la vente directe sur Internet c'est récent et encore marginal.

Moi je n'achète quasiment plus de CD dans les grandes enseignes (je pense 1 voire 2 par an, mais c'est tout), par contre j'aime bien aller voir directement les labels pour leur acheter leur musique. Avec la démocratisation d'Internet, ça se développe de plus en plus.

Quelques exemples dans mes goûts :
http://www.recordstore.co.uk/brownswoodrecordings/
http://www.ninjatune.net/ninjashop/
http://www.sonarkollektiv.com/shop/

Et en plus c'est en général pas trop cher.

P.S.: oui, ces labels sont quand même parfois en relation avec les majors (liens iTunes chez Brownswoods, Sonar Kollektiv en relation avec Universal et Verve, ...) mais j'ose espérer qu'en passant directement par leurs shops ça les aide à "décrocher".

connecte sur mon entreprise [...] route les paquets via ssh [...] 172.54.56.88 (intranet) [...] n'autorise le port 22 de 198.66.53.46 (ce que j'ai nommé la passerelle) que pour le proxy et non pour mon adresse privée qui se trouve derrière le proxy.
Bon, je suis désolé, mais tu ne connais pas assez le réseau pour essayer de faire un truc qui peut marcher comme tu as l'air de raconter (ce que je cite c'est toutes les bourdes qui ne veulent rien dire). C'est de plus super tordu, je trouve, par rapport à une solution plus simple comme nono14 indique.

Pour moi, ton problème chez le client c'est juste qu'il bloque le port 22, point. Un proxy http (genre squid) permet d'aller sur le web pour le http, c'est bien, mais en dehors de ça, je suppose que chez ton client tout accès "direct" au net est prohibé. Donc pas de SSH.
Après, tu peux essayer de bidouiller avec le proxy, voire déjà s'il autorise le CONNECT, sur le port 22 ce serait mieux, ou sinon sur le 443 comme indique nono14 ça a plus de chances de passer. Après, si le CONNECT est bloqué (ou le deviendra, puisque c'est un contournement de la politique de sécurité et ça se verra un jour) il te reste le GET/POST classique avec un tunnel qui va bien, du polling et tout le bazarre .... Bref, c'est très crade.

Enfin bref, ta solution, selon moi, c'est soit que ton entreprise trouve une solution adaptée (et moins galère ...) à tes clients, soit de dire à tes clients d'arrêter de faire les prudes avec leur "politique de sécurité" (OK, je m'avance un peu sur leur niveau de connaissance, mais les politiques de sécu sont souvent à deux vitesses ...)

Bon, et quelques conseils si tu gardes ta méthode : ton espèce de port knocking, c'est chiant et galère, pourquoi n'ouvres-tu pas directement le 22 sur 198.66.53.48 ? Ensuite, ton tunnel SSH (-L ...:...:...) c'est un peu gore, moi j'aurais "simplement" fait du port forwarding vers 172.54.56.88 (qui n'est pas une adresse privée selon la "norme", mais bon ...).

Voilà, si en plus tu as fait tout ça parce que l'admin de ta boite est borné est n'a pas de meilleure solution, ça fait un double contournement de sécurité, donc pour ton taf je te souhaite bon courage.

Encore quelques points pas clairs :
"cette passerelle" : quelle passerelle ? Tu n'as pas encore parlé de passerelle ...
Ensuite, tu parles (chez le client) de l'IP du proxy derrière lequel tu as une autre IP : dans ce que j'imagine, derrière un proxy tu auras (en général) une adresse privée, donc depuis l'extérieur (ton entreprise) tu auras tout le temps l'adresse du proxy.
D'ailleurs, un proxy qui "autorise le port 22" ça ne veut rien dire, vu qu'un proxy ne fait normalement que du HTTP/FTP (ou alors détaille un peu plus ce que c'est).

Bref, ce n'est toujours pas très cohérent, ce serait bien de savoir si c'est parce que tu expliques mal, ou que tu connais mal le réseau.

... à une citation récente [http://lambda-the-ultimate.org/node/3619] :
"Mock objects and dependency injection are just for people who don't know math" - Erik Meijer

Franchement, je comprend à peine ton problème. Essaye de mettre des virgules et des points où il faut, et de reformuler plus clairement.

Oui, linuxfr est hébergé par le fondation Free.

Non, leur réseau n'est pas IPv6-capable, il est encapsulé dans du v4 jusqu'à leur PoP v6.

On en a déjà parlé ici et un des admins de linuxfr a dit que comme Free ne fait pas, linuxfr ne fait pas non plus.

J'ai posé la question de "bah, pourquoi pas migrer ailleurs alors ?", genre FDN. Je ne sais plus trop ce que ça a donné, sûrement un "bah alors juste fais le".

Sinon, pour le "gros" travail, peut-être au début pour templeet (pour la gestion de session) et le setup de la machine, mais après, ça doit rouler tout seul.

Si ça marche avec une Ubuntu "récente", ya une problème chez Debian, et il faudrait le signaler (bizarre qu'avec un 2.6.30 ça déconne ...)

Journal très bien fait, information importante, mérite une dépêche selon moi.

J'ai fait des install LVM (+RAID) mais sans chiffrement sous Debian, et tu peux choisir de mettre LVM où tu veux : sur tout le disque, sur une "partition classique" particulière (un PV, quoi), ou plusieurs, etc. LVM est très flexible, je ne pense pas qu'il bloque quoi que ce soit. (après, oui, c'est le debian-installer, je ne sais pas ce que valent les autres ... je sais juste que l'installeur Ubuntu ne gère pas LVM)

Tu t'entraînes pour demain, c'est ça ?

Si t'as le problème en SSH, c'est peut-être qu'il garde la locale du système depuis lequel tu te loggues ?

Juste une petite remarque (je suis d'accord avec la majorité de ta prose) : pour moi, investir dans un réseau IPv6 et décentralisé (qui pour moi vont de pair) permettrait de réduire la charge des vidéos sur le net, si on développait un peu plus le P2P (qui a besoin d'un réseau "plat" et pas plein de NAT dans tous les sens).

Problème, les gros sites centralisés et les ayants-droits perdraient un peu du contrôle de diffusion qu'ils ont sur ce contenu, et ça ils n'aiment pas du tout.

Si le traffic était un peu mieux réparti et moins centralisé, on aurait moins les déséquilibres de peering qu'on connaît actuellement.

OK, j'en avais déjà entendu parler. Je trouvais ça dommage au début, mais en fait en lisant la RFC4966 ça se comprend : encore un autre nouveau système à éprouver, et tous les problèmes liés aux différences entre IPv4 et IPv6 (en plus fait que le NAT-PT serait sûrement pas entièrement compatible avec IPv6).

Donc pour moi, le dual-stack reste toujours _la_ solution. (et existe déjà dans Windows XP, MacOS X et Linux ...)

Tout d'abord, merci pour les éclaircissements, je sais que je me perd moi aussi des fois dans les longs thread sur linuxfr; pas de problème !

1) Ha d'accord, déjà je ne l'avais pas compris comme ça. D'ailleurs, après relecture, je le "comprend" autrement, mais pas comme "du NATv4 est la solution définitive" ! Ça m'emmerde aussi, et je ne comprend pas le problème qu'il y a avec le dual-stack : oui, on fait du dual alors qu'en v4 on sera bientôt tous NATés, mais même derrière du NATv4 la stack v4 est quand même utile ! Et pour encore pour un bon bout de temps selon moi !
2) C'est quoi le NAT pur v4 ? Sans v6 ? Ce n'est pas ce que j'appelle une transition ... (donc à un moment, hop, on switch tous en v6 only en même temps en espérant que ça marche ? irréaliste ...)
3) Effectivement, mais si on fait quelques efforts, on peut en trouver.
4) Effectivement, mais si on fait quelques efforts, on peut en trouver.
5) Oui, c'est long, mais plus c'est long ...
6) C'est quoi un NAT mixte ? (désolé pour mes questions naïves, j'ai souvent une idée du truc, mais c'est pour être clair) C'est du v4 NATé + v6 routé ? C'est ce que j'ai chez moi et ça marche du tonnerre.

Moi, je ne vois pas de théorie du complot ou rien d'amusant là-dedans comme dit dans le premier post du fil. Je vois juste une analyse de la situation (et une tentative d'explication) : "les fournisseurs ne migrent pas vers ipv6".
Moi aussi .... et LoninoL aussi je pense .... en fait, on est tous d'accord \o/

Je pense que c'est lui qui inverse la cause et la conséquence. Le nat V4 n'était pas là au départ comme truc de transition vers ipv6 mais pour prolonger la vie d'ipv4
Peut-être, je ne connais les détails, mais la RFC que tu cites n'a pas un rapport direct : elle ne parle pas de NAT, mais elle parle bien du fait qu'a l'époque on pensait qu'avoir une adresse publique pour tout le monde n'était pas utile (d'ailleurs il me semblait que c'était plus vieux, ça m'étonne de voir 1996 !). Pour le NAT : http://tools.ietf.org/html/rfc1631 et l'IPv6 est cité comme solution à long terme, donc on peut peut-être classer le NAT comme mécanisme de transition ?... De toutes manières, pour moi, il est bien dans l'un ou l'autre des rôles, ça ne me dérange pas.

Et oui, tu as été plus clair :-)

Tu peux pas faire deux CSS, une avec les commentaire en display:none, et une autre sans ?

Donc en fait la seule puce sur laquelle un driver libre avec OpenGL fonctionnel existe est celle pour lequel ta version de Gnash ne marche pas bien ? ("prochainement / pas encore testé")
Dommage ....

Enfin, merci quand même pour l'effort.

Je rajouterais dans ta liste :

Faire un standard pour que des gens implémentent des outils de création, mais qui interdit la création d'un player.

(OK, ce n'est normalement plus le cas actuellement, mais ça l'a été pendant des années).

Petite précision, je suis peut-être un peu "vif" dans mes réponses, mais c'est vraiment parce que je ne comprend _réellement_ pas où eest le problème. J'ai déjà entendu d'autres personnes qui voulaient un "autre" méchanisme de transition, plus mieux, plus facile, etc, mais n'ayant absolument aucune idée de ce que ça pourrait être. Je ne les comprend (sérieusement) pas du tout ...

Gni ? C'est un non-problème.

Pourquoi penses-tu que certains utilisateurs n'auront plus qu'une adresse IPv6 ? Le NAT v4 est la solution temporaire, il apporte des problèmes, mais pour les résoudre sur le long terme on a IPv6.

Je ne vois pas où est le problème. Si tu veux une solution qui apporte une adresse publique IPv4 à tout le monde alors qu'il n'y en n'a plus assez, je pense que tu peux chercher encore longtemps ...

Bah, le "Oui, et ?", et :
Mais pour le moment, ce n'est pas une translation de ipv6 vers ipv4 pour compatibilité c'est ipv4 vers ipv4 ce qui n'apporte rien au schmilblick.
Ensuite tu parles des NAT v6 to v4, et que "rien n'est prêt pour une quelconque migration."

Pour moi, si, la migration est "en cours", les outils sont là, on attend que les FAI et autres gens qui s'occupent du réseau se bougent le cul. La transition est faite pour être _invisible_ à l'utilisateur.

Tant qu'on y est, faudrait peut-être que tu testes avec une autre distro, un système "propre", ou un live. Et plus de détails sur ta config (carte-mère ? etc)

Ha, joli lancé de troll sur la lenteur de Java ...