La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Bouygues Telecom => 
5G/4G Bouygues Telecom => Discussion démarrée par: Boris de Bouygues Telecom le 27 novembre 2011 à 14:56:59
-
Aujourd'hui je suis connecté en clé 3G (en indor, dans le val de marne) sans VPN.
L’occasion de faire un petit SpeedTest avec ma clé 3G Bouygues Telecom Huawei E180 (un modèle classique qui date un peu mais qui marche bien - reconnu sous Linux Ubuntu sans rien faire - pas de drivers à installer, il pose uniquement une questions lors de la première connexion : il faut sélectionner le FAI et l'offre dans une liste déroulante.)
Serveur de Paris :
(https://lafibre.info/images/bbox/201111_speedtest_3G_indor_val_de_marne_1.png)
Serveur d'Aubervilliers
(https://lafibre.info/images/bbox/201111_speedtest_3G_indor_val_de_marne_2.png)
Serveur de Clichy :
(https://lafibre.info/images/bbox/201111_speedtest_3G_indor_val_de_marne_3.png)
Serveur de Lyon :
(https://lafibre.info/images/bbox/201111_speedtest_3G_indor_val_de_marne_4.png)
Serveur de Roubaix :
(https://lafibre.info/images/bbox/201111_speedtest_3G_indor_val_de_marne_5.png)
L'interface avec un ifconfig : (sur mon Linux Ubuntu 11.10)
$ ifconfig
[...]
ppp0 Link encap:Protocole Point-à-Point
inet adr:10.174.141.207 P-t-P:10.64.64.64 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
Packets reçus:401069 erreurs:0 :0 overruns:0 frame:0
TX packets:271383 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
Octets reçus:552396826 (552.3 MB) Octets transmis:39404319 (39.4 MB)
$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 10.64.64.64 0.0.0.0 UG 0 0 0 ppp0
10.64.64.64 * 255.255.255.255 UH 0 0 0 ppp0
link-local * 255.255.0.0 U 1000 0 0 ppp0
-
Intéressant...
Je suis surpris, car apparemment, il n'y a pas d'IP publique... A moins que je ne me trompe. A moins aussi que Bouygues ne fasse du "one to one nat"? Ca m'étonnerai quand même.
Mais si c'est du vrai NAT, c'est vraiment moche! Certains VPN (d'entreprise) fonctionnent très mal sans IP publique.
Même avec des connexions par modem 56k, on a des IP publiques.
Tu peux nous en dire plus?
Leon.
-
Leon_m, tu n'a jamais utilisé une clé 3G ?
Quel que soit l'opérateur (y compris les MVNO), les IP récupérées sont des IP privée derrière un NAT (cf Article de FDN (http://blog.fdn.fr/?post/2010/03/22/Pourquoi-l%e2%80%99Internet-mobile-n%e2%80%99est-PAS-Internet)). Ce NAT n'est pas un "one to one nat" mais le nombre d'abonné derrière un NAT est assez faible afin que les VPN d'entreprises puissent monter.
Des offres entreprises spécifiques permettent d'avoir une IPv4 publique (IPv4 fixe si demandé) mais pour le grand public je ne connaît qu'une association que cherche à faire un forfait 3G sans aucune limite avec IPv4 fixe et une plage IPv6 par clé 3G, mais je n'ai pas retrouvé le lien. Ils attendent d'avoir 1000 demandes de forfait 3G pour prendre un forfait entreprise chez Bouygues Telecom et récupérer le trafic sur TH2. Là il montent leur propre plages IPv4 et IPv6 et transit IP (acheté à FDN / Gitoyen).
Boris.
-
France Wireless (sur clubic (http://www.clubic.com/telephone-portable/forfaits-3g-illimites/actualite-435544-forfait-3g-france-wireless.html) par exemple). Par contre je ne savais pas qu'ils comptaient se fournir chez ByTel, intéressant ;-)
Effectivement l'internet mobile est bien loin de ce que l'on connait sur le fixe, entre le NAT et les ports bridés (pas chez tout le monde, certes).
Concernant les débits ... euh ... on est loin de la moyenne nationale :D
La clé est capable de monter à 7.2Mb théorique c'est ça ? (je me fie à la fiche (http://www.entreprises.bouyguestelecom.fr/bte/content/download/32118/234926/version/1/file/Fiche%2520Huawei%2520E180.pdf) sur le site)
-
Leon_m, tu n'a jamais utilisé une clé 3G ?
Quel que soit l'opérateur (y compris les MVNO), les IP récupérées sont des IP privée derrière un NAT (cf Article de FDN (http://blog.fdn.fr/?post/2010/03/22/Pourquoi-l%e2%80%99Internet-mobile-n%e2%80%99est-PAS-Internet)). Ce NAT n'est pas un "one to one nat" mais le nombre d'abonné derrière un NAT est assez faible afin que les VPN d'entreprises puissent monter.
Non, je n'ai jamais utilisé de clé 3G. Mais là, franchement, c'est complètement incompréhensible, le fait de ne pas avoir d'IP publique. OK, pour un téléphone portable, je peux comprendre: un téléphone est connecté 24h/24, et le nombre d'applications qui auraient besoin d'une IP publique, ça reste limité.
Mais avec un PC, c'est complètement différent! Encore une fois, la comparaison avec les vieux modems 56k est frappante: l'accès 56k ne coute quasiment rien, et avec des débits tout pourris. Et pourtant, on a une IP publique. En comparaison, un accès 3G est hors de prix, et avec un débit beaucoup plus élevé que le 56k. Donc ça n'est pas du tout cohérent.
Bref, ça n'a pas de sens! Encore une fois, certaines applications fonctionnent très mal sans IP publique (les VPN par exemple). Qu'est-ce qui empêche les 3 opérateurs de fournir une IP publique? Quel intérêt ont-ils à ne pas fournir d'IP publique? Ca n'est pas un intérêt économique, car faire du NAT massif, ça nécessite des équipements supplèmentaires qui ne sont pas gratuits.
Bref, si les 3 opérateurs mobiles font tous ça, ça confirme ce que je pense d'eux : bien au chaud dans leurs pantouffles, aucune innovation, des services limités et des tarifs exhorbitants...
Leon.
-
Avec du nat il est pas plus facile de filtré les protocole genre p2p, voip ?
-
Free arrive bien à "shaper" (parfois à 0.0001 Kbps) tout sauf le Web, chez les IP/ADSL, sans aucun NAT!
-
Free utilisait des Cisco SCE 2000 (https://lafibre.info/tester-son-debit/verifier-si-votre-connexion-est-bridee-par-un-cisco-sce-2000/) en zone non dégroupé pour limiter le trafic de collecte à un débit fixe (le débit étais toujours le même de jour comme de nuit, en heure de pointe, comme le dit Correcor, le P2P étais presque coupé et le protocole suivant sur la liste (FTP) étais dégradé alors que le HTML et les jeux restaient au débit max. La nuit la consommation http diminuant, le P2P pouvait reprendre du service sans dépasser la limite totale du trafic de collecte fixé par Free.
-
ssh et les newsgroups étaient rangés avec le "P2P"!
-
Avec du nat il est pas plus facile de filtré les protocole genre p2p, voip ?
Eh non. Comme a essayé de le montrer Vivien: un firewall "de base" ou un firewall "intelligent" qui analyse le contenu des différent paquets pour reconnaitre précisèment l'application qui se cache derrière, ça peut fonctionner avec ou sans NAT, donc avec des adresses publiques ou privées. Clairement, l'explication n'est pas là, et d'ailleurs, je ne pense pas qu'il y ait d'explication. Je pense juste que nos 3 opérateurs sont trop fénaiants pour fournir quelque chose de différencié entre les "clé 3G" et les forfaits smartphone d'un point de vue technique.
Bref, c'est tout pourri, mais tant pis, vu que les consommateurs payent et qu'il n'y a pas de réelle concurrence.
Leon.
-
Je me demande si ce n'est pas pour économiser tout le trafic de scan qui est envoyé a toutes les IP publiques.
Quand on regarde sur une IP publique, il y a en permanence du trafic. Petit trafic mais suffisant pour réserver les ressources radios (pour simplifier, elles sont libérées en cas d'absence de trafic pendant quelques secondes).
Quand on voit les personnes qui ont peur de mettre une DMZ sur leur box (https://lafibre.info/kiwi-fibre-optique/93mbits-en-bypassant-la-box/msg39545/#msg39545), je pense qu'elles sont plus sécurisée de savoir qu'elles sont derrière un NAT.
C'est l'explication auquel je pense mais il y a peut-être une meilleure raison...
On verra ce que choisit de faire Free... La sortie de l'offre Free mobile est dans quelques jours ;)
-
A tout hasard, est-ce qu'à l'époque du choix de NATer les réseaux mobiles, on avait déjà une vision de la pénurie d'adresses ipv4 à venir ?
D'ailleurs cette pénurie n'empêcherait pas Free de donner des adresses publiques lors du lancement (qui approche) ?
Et dernière question par rapport à ton post, avec le push de partout (mail, applis, etc) on prends des ressources radio sans cesse non ?
-
Je me demande si ce n'est pas pour économiser tout le trafic de scan qui est envoyé a toutes les IP publiques.
Quand on regarde sur une IP publique, il y a en permanence du trafic.
Il est vrai qu'il existe un "bruit de fond" du net, surtout les ports des protocoles Windows (Netbios, SMB...), Unix (ssh), et des serveurs et proxy HTTP. (Si ils trouvent un serveur accessible, ils font des scan de nom de d'utilisateur et de mot de passe...)
N'importe quel PC bien configuré n'a strictement rien à craindre de ce genre de choses. Mais ça reste une pollution; moi, je n'aime pas voir des paquets non désirés dans mon tcpdump, parce que c'est une distraction! Des connexions ssh non désirées, c'est aussi du temps CPU perdu (des exponentielles de grand nombres entiers calculées pour rien), et aussi des lignes de log qui sont sans intérêt : encore une distraction.
Même si on sait qu'on n'a rien à craindre de ce genre d'attaque (p.ex. si sshd n'accepte que des logins par clé publique), on peut vouloir s'en protéger.
Petit trafic mais suffisant pour réserver les ressources radios (pour simplifier, elles sont libérées en cas d'absence de trafic pendant quelques secondes).
Je ne savais pas.
De toute façon, on peut avoir envie de bloquer un certain type de trafic entrant avant la boucle locale. J'ai toujours été favorable à ce que l'utilisateur puisse placer un pare-feu sur le DSLAM, même le plus simple pare-feu sans état.
-
Et dernière question par rapport à ton post, avec le push de partout (mail, applis, etc) on prends des ressources radio sans cesse non ?
Je ne vois pas pourquoi!
Le principe du push est justement de prévenir d'un évènement, et donc d'éviter tout trafic inutile tant que cet évènement n'a pas lieux.
-
Le push mail faisant que les mails arrivent presque plus vite sur mon smartphone que mon PC, je me suis dit que ça impliquait une connexion constante au serveur de messagerie.
-
Exactement.
-
J'ai cru comprendre (ce n'est pas mon domaine de compétence) que les appli de chat sur mobile (type jabber / msn) sont entraîne une consommation de ressource élevée (par rapport à une consommation IP qui reste assez faible)
Pour les IP publique, Free a trompé le RIPE pour obtenir beaucoup IP d'avance (demander plusieurs IPv4 publiques par abonné pour le service Free WiFi). Free est un des FAI à avoir le plus d'IPv4 en stock et je ne pense pas que FreeWifi consomme 10 millions d'IP...
-
Exactement.
Donc une bonne partie des smartphones consomment de la ressource radio sans cesse. Non ? (ou alors j'ai mal compris ton post précédent corrector)
-
Donc une bonne partie des smartphones consomment de la ressource radio sans cesse.
Pourquoi voudrais-tu qu'une connexion utilise "sans cesse" le réseau?
-
Je me fais peut-être une mauvaise idée mais en gros :
Il y a une connexion ouverte entre mon smartphone et le serveur de messagerie sans cesse pour permettre le push -> il existe un lien "ininterrompu" entre les deux -> la ressource radio est réservée pour maintenir ce lien.
J'ai peut-être fait un raccourci/pas compris un truc après, je ne dis pas le contraire.
-
Je me fais peut-être une mauvaise idée mais en gros :
Il y a une connexion ouverte entre mon smartphone et le serveur de messagerie sans cesse pour permettre le push -> il existe un lien "ininterrompu" entre les deux -> la ressource radio est réservée pour maintenir ce lien.
J'ai peut-être fait un raccourci/pas compris un truc après, je ne dis pas le contraire.
Franchement, vu comme les opérateurs mobiles sont radins, si c'était contraignant pour eux d'avoir des téléphones tout le temps connectés, je pense qu'ils fixeraient des limites! Personnellement, je paye moins de 15€/mois, et je peux pourtant rester connecté toute la journée, garder une connection permanente, si je consomme peu de data. Et je crois que les applications spécialement conçues pour être "always on" come le tchat ou le push-mail consomment le minimum possible: quelques paquets toutes les 5 minutes ou quelque chose comme ça.
Leon.
-
Est-ce que ces "quelques paquets toutes les 5 minutes" permettent aux mails d'arriver dans la seconde qui suit leur envoi sur mon terminal ?
Quand je lis ça :
Push email is used to describe email systems that provide an always-on capability, in which new email is actively transferred (pushed) as it arrives by the mail delivery agent (MDA) (commonly called mail server) to the mail user agent (MUA), also called the email client. Email clients include smartphones and, less strictly, IMAP personal computer mail applications.
J'ai du mal à délier le "always-on" à "réservation de ressource radio". Alors si c'est bien le cas je suis preneur d'une explication.
J'ai vraiment du mal à comprendre comment les smartphones ne réservent pas des ressources radio tout le temps quand le push est activé de partout (mail, applis, etc.).
-
J'ai du mal à voir comment tu lies "always-on" à "réservation de ressource radio" : comment tu vois le "push", concrètement?
-
Je me méprends peut-être mais j'aurais tendance à voir une connexion active permanente entre le téléphone et le serveur de messagerie (exchange ou autre), et dans ma tête ça implique de la ressource radio utilisée / une connexion data maintenue.
En fait je pense qu'après avoir entendu plusieurs fois que le push entrainait une augmentation du trafic data et une baisse de l'autonomie, j'étais parti du principe qu'il se passait qqch sans cesse pour permettre cette réactivité.
-
Est-ce que ces "quelques paquets toutes les 5 minutes" permettent aux mails d'arriver dans la seconde qui suit leur envoi sur mon terminal ?
Clairement, oui! Ca permet de maintenir une connexion TCP en vie, et je crois que c'est le minimum vital. Et dès que le serveur a un événement à annoncer au terminal, il utilise cette connexion TCP unique, et le terminal réagit instantannèment.
Leon.
-
Bon, sans vouloir paraître insistant, j'ai du mal à visualiser la connexion TCP ouverte sur un lien radio fermé. Est-ce que tu as un lien expliquant tout ça (j'imagine que ça ne s'applique pas uniquement au mobile ce cas de figure) ?
-
Si il n'y a pas de paquets qui passent, les ressources sont libérées jusqu’à ce qu'un des deux coté (le client ou le serveur èmette un paquet).
Exemple du push qui ne consomme par de ressourcer radio : Le SMS
Le problème du bruit avec une IP publique c'est que le serveur envoi presque toutes les secondes un paquet.
-
Le lien radio n'est ni "ouvert" ni "fermé", il est plus ou moins utilisé. C'est comme une route où il passe une voiture toutes les 5 mn, elle n'est pas fermée, mais c'est moins bruyant pour les riverains que s'il passe une voiture toutes les 5 s.