Quelle ne fut pas ma surprise de constater qu'il était possible, avec
l'ADSL, de se connecter simultanément à deux (pas essayé à plus de 2) sur le
même compte d'un FAI, avec les mêmes paramètres (login = password) !
Aucun message d'alerte ou quoi que ce soit ! D'ailleurs les CGV de plusieurs
FAI signalent que c'est interdit et reconnaissent donc implicitement que
c'est possible !!!!!!
Une question demeure : est-ce possible quand les 2 personnes sont abonnées
chez des FAI différents (nous sommes, pour notre part, chez le même). Je ne
pense pas mais, après tout, pourquoi pas, si les FAI utilisent le même
réseau dégroupé.
Plus fort encore, nous avons fait l'essai avec un ami qui a une IP fixe.
Résultat : connectés simultanément sur le même compte avec...la même IP
!!!!!
Bonjour la sécurité... Comment prouver alors que ce n'est pas vous qui avez
fait telle ou telle chose répréhensible sur le Net ???
Pour compléter le tout, nous avons fait des essais de connexions simultanées
sur des Webmails. Les conclusions sont tout aussi incroyables : Hotmail et
Yahoo (nos premiers essais) le permettent sans rechigner ! Pas même de
message signalant que la boite est déjà consultée... Je précise que pour
Yahoo, l'essai a été fait avec et sans l'option "Sécurisé".
Suis-je le seul à halluciner ? Ces faits sont-ils déjà connus depuis
longtemps ? N'existe-t-il aucune parade ?
"La Piovra" a écrit dans le message de news:422eb7cb$0$310$
Hello,
Plus fort encore, nous avons fait l'essai avec un ami qui a une IP fixe. Résultat : connectés simultanément sur le même compte avec...la même IP !!!!!
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
"La Piovra" <juju_lb.nospam@hotmail.com> a écrit dans le message de
news:422eb7cb$0$310$7a628cd7@news.club-internet.fr...
Hello,
Plus fort encore, nous avons fait l'essai avec un ami qui a une IP fixe.
Résultat : connectés simultanément sur le même compte avec...la même IP
!!!!!
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y
a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse
identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de
détails, parce que je ne vois pas comment c'est possible.
"La Piovra" a écrit dans le message de news:422eb7cb$0$310$
Hello,
Plus fort encore, nous avons fait l'essai avec un ami qui a une IP fixe. Résultat : connectés simultanément sur le même compte avec...la même IP !!!!!
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
La Piovra
"Patrick RoZ" a écrit dans le message de news: 422f005c$0$11715$
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
Mais non, pas de routeur. Nous n'habitons pas la même ville, nous avons 2 lignes tel bien distinctes, 2 abonnements ADSL chez le même FAI mais pas la même formule et nous avons réussi à nous connecter à 2 avec le même couple login/pw !
Comme l'autre personne avait une IP fixe (option téléphonie VoIP), je me suis connecté avec la même IP que lui, en simultané avec possibilité de surfer (certes, apparemment pas au débit max mais quand même).
Inquiétant, non ?
Je n'y aurais pas crû si je ne l'avais pas vu !
"Patrick RoZ" <patrick.detrop.roz@tiscali.invalid> a écrit dans le message
de news: 422f005c$0$11715$8fcfb975@news.wanadoo.fr...
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il
n'y
a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse
identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de
détails, parce que je ne vois pas comment c'est possible.
Mais non, pas de routeur. Nous n'habitons pas la même ville, nous avons 2
lignes tel bien distinctes, 2 abonnements ADSL chez le même FAI mais pas la
même formule et nous avons réussi à nous connecter à 2 avec le même couple
login/pw !
Comme l'autre personne avait une IP fixe (option téléphonie VoIP), je me
suis connecté avec la même IP que lui, en simultané avec possibilité de
surfer (certes, apparemment pas au débit max mais quand même).
"Patrick RoZ" a écrit dans le message de news: 422f005c$0$11715$
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
Mais non, pas de routeur. Nous n'habitons pas la même ville, nous avons 2 lignes tel bien distinctes, 2 abonnements ADSL chez le même FAI mais pas la même formule et nous avons réussi à nous connecter à 2 avec le même couple login/pw !
Comme l'autre personne avait une IP fixe (option téléphonie VoIP), je me suis connecté avec la même IP que lui, en simultané avec possibilité de surfer (certes, apparemment pas au débit max mais quand même).
Inquiétant, non ?
Je n'y aurais pas crû si je ne l'avais pas vu !
Francois Petillon
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable). De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la gestion des sessions TCP sur le LNS que va se poser le probleme (là, on parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
François
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y
a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse
identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de
détails, parce que je ne vois pas comment c'est possible.
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera
toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP
ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable).
De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la
gestion des sessions TCP sur le LNS que va se poser le probleme (là, on
parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et
tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de
pertes.
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
A moins que votre ami et vous même utilisiez un routeur (dans ce cas il n'y a rien de choquant à ce que vos ordinateurs aient tous 2 une adresse identique comme 192.168.0.1 par exemple), soit il faudrait donner plus de détails, parce que je ne vois pas comment c'est possible.
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable). De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la gestion des sessions TCP sur le LNS que va se poser le probleme (là, on parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
François
JL
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt, puisqu'il faut de toutes façons avoir une ligne ADSL, donc que chacun paye un abonnement.
JL.
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt, puisqu'il
faut de toutes façons avoir une ligne ADSL, donc que chacun paye un
abonnement.
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt, puisqu'il faut de toutes façons avoir une ligne ADSL, donc que chacun paye un abonnement.
JL.
La Piovra
"JL" a écrit dans le message de news: 422f48ef$0$27838$
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt, puisqu'il faut de toutes façons avoir une ligne ADSL, donc que chacun paye un abonnement.
JL.
En l'occurence, il s'agit de 2 lignes dégroupées. Quant à l'intérêt, il est nul, nous sommes tout à fait d'accord là-dessus. Je trouve juste ça très limite d'un point de vue sécurité et confidentialité.
"JL" <JL@jlamy.com> a écrit dans le message de news:
422f48ef$0$27838$626a14ce@news.free.fr...
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt,
puisqu'il faut de toutes façons avoir une ligne ADSL, donc que chacun paye
un abonnement.
JL.
En l'occurence, il s'agit de 2 lignes dégroupées.
Quant à l'intérêt, il est nul, nous sommes tout à fait d'accord là-dessus.
Je trouve juste ça très limite d'un point de vue sécurité et
confidentialité.
"JL" a écrit dans le message de news: 422f48ef$0$27838$
Ce n'est possible qu'en non dégroupé. Et ça n'a pas grand intérêt, puisqu'il faut de toutes façons avoir une ligne ADSL, donc que chacun paye un abonnement.
JL.
En l'occurence, il s'agit de 2 lignes dégroupées. Quant à l'intérêt, il est nul, nous sommes tout à fait d'accord là-dessus. Je trouve juste ça très limite d'un point de vue sécurité et confidentialité.
La Piovra
"Francois Petillon" a écrit dans le message de news:
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable). De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la gestion des sessions TCP sur le LNS que va se poser le probleme (là, on parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
François
Désolé, mais j'ai décroché ;-) C'est un peu trop technique pour moi. C'est quand même hallucinant et je ne trouve pas ça très "safe".
"Francois Petillon" <fanch@fanfan.staff.proxad.net> a écrit dans le message
de news: pan.2005.03.09.17.14.57.364281@fanfan.staff.proxad.net...
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera
toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP
ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable).
De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la
gestion des sessions TCP sur le LNS que va se poser le probleme (là, on
parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et
tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de
pertes.
François
Désolé, mais j'ai décroché ;-) C'est un peu trop technique pour moi.
C'est quand même hallucinant et je ne trouve pas ça très "safe".
"Francois Petillon" a écrit dans le message de news:
On Wed, 09 Mar 2005 14:55:41 +0100, Patrick RoZ wrote:
Techniquement, ce n'est pas impossible. Déjà parce qu'une IP fixe sera toujours gérée par le même LNS (derriere le LNS, c'est un tunnel) en IP ADSL (je présume que c'est de l'IP ADSL ou une architecture semblable). De ce fait, le routage jusqu'au LNS est unique. En fait, c'est sur la gestion des sessions TCP sur le LNS que va se poser le probleme (là, on parle pas d'UDP). Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
François
Désolé, mais j'ai décroché ;-) C'est un peu trop technique pour moi. C'est quand même hallucinant et je ne trouve pas ça très "safe".
Pascal
Salut,
Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
Pour info, il a été rapporté que c'est le deuxième cas qui se produit chez Nerim. Une moitié des paquets part vers chacune des deux connexions ayant la même IP.
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la Netfilter avec marquage des paquets retour pour les aiguiller vers la bonne session PPP ?
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Salut,
Soit le LNS est capable de gerer les sessions TCP et
tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de
pertes.
Pour info, il a été rapporté que c'est le deuxième cas qui se produit
chez Nerim. Une moitié des paquets part vers chacune des deux connexions
ayant la même IP.
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la
Netfilter avec marquage des paquets retour pour les aiguiller vers la
bonne session PPP ?
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à
intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses
comme du filtrage administratif). Il n'a pas déjà assez de boulot à
maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
--
Pascal
Vous pouvez me tutoyer.
Piège à spam : boite-a-spam@plouf.fr.eu.org
Soit le LNS est capable de gerer les sessions TCP et tout se passe bien, soit il ne le fait pas et on risque d'avoir 50% de pertes.
Pour info, il a été rapporté que c'est le deuxième cas qui se produit chez Nerim. Une moitié des paquets part vers chacune des deux connexions ayant la même IP.
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la Netfilter avec marquage des paquets retour pour les aiguiller vers la bonne session PPP ?
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Francois Petillon
On Wed, 09 Mar 2005 23:23:07 +0100, wrote:
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la Netfilter avec marquage des paquets retour pour les aiguiller vers la bonne session PPP ?
Oui.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Pas forcement. Il y a des FAIs qui aiment bien le NAT et certains constructeurs ont probablement déjà mis en place des solutions hardware.
François
On Wed, 09 Mar 2005 23:23:07 +0100, Pascal@plouf wrote:
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la
Netfilter avec marquage des paquets retour pour les aiguiller vers la
bonne session PPP ?
Oui.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à
intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses
comme du filtrage administratif). Il n'a pas déjà assez de boulot à
maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Pas forcement. Il y a des FAIs qui aiment bien le NAT et certains
constructeurs ont probablement déjà mis en place des solutions hardware.
Qu'entends-tu par "gérer les sessions TCP" ? Suivi de connexion à la Netfilter avec marquage des paquets retour pour les aiguiller vers la bonne session PPP ?
Oui.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Pas forcement. Il y a des FAIs qui aiment bien le NAT et certains constructeurs ont probablement déjà mis en place des solutions hardware.
François
Raphael Bouaziz
Le Wed, 09 Mar 2005 23:23:07 +0100, a écrit dans le message <d0nsug$2dkk$ :
Pour info, il a été rapporté que c'est le deuxième cas qui se produit chez Nerim. Une moitié des paquets part vers chacune des deux connexions ayant la même IP.
C'est vrai si l'on tombe sur le même LNS ou sur deux LNS du même site.
Sinon il y a des sombres histoires de métriques IGP que je ne détaillerai pas, qui font que tous les paquets peuvent aller vers une connexion, et aucun vers l'autre.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS à fragmenter le paquet : économie de CPU ...
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
-- Raphael Bouaziz.
Le Wed, 09 Mar 2005 23:23:07 +0100, Pascal@plouf a écrit
dans le message <d0nsug$2dkk$1@biggoron.nerim.net> :
Pour info, il a été rapporté que c'est le deuxième cas qui se produit
chez Nerim. Une moitié des paquets part vers chacune des deux connexions
ayant la même IP.
C'est vrai si l'on tombe sur le même LNS ou sur deux LNS du même site.
Sinon il y a des sombres histoires de métriques IGP que je ne détaillerai
pas, qui font que tous les paquets peuvent aller vers une connexion, et
aucun vers l'autre.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à
intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses
comme du filtrage administratif). Il n'a pas déjà assez de boulot à
maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière
à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS
à fragmenter le paquet : économie de CPU ...
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
Le Wed, 09 Mar 2005 23:23:07 +0100, a écrit dans le message <d0nsug$2dkk$ :
Pour info, il a été rapporté que c'est le deuxième cas qui se produit chez Nerim. Une moitié des paquets part vers chacune des deux connexions ayant la même IP.
C'est vrai si l'on tombe sur le même LNS ou sur deux LNS du même site.
Sinon il y a des sombres histoires de métriques IGP que je ne détaillerai pas, qui font que tous les paquets peuvent aller vers une connexion, et aucun vers l'autre.
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS à fragmenter le paquet : économie de CPU ...
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
-- Raphael Bouaziz.
Pascal
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS à fragmenter le paquet : économie de CPU ...
C'est déjà moins lourd de repérer et modifier les paquets SYN que de faire du suivi d'état de connexions TCP, non ? C'est pour éviter de fragmenter les paquets IP encapsulés ou aussi les paquets L2TP qui les transportent tant qu'on y est ?
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
Sympa, merci. :) D'après la valeur 1420, je penche pour la seconde hypothèse.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à
intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses
comme du filtrage administratif). Il n'a pas déjà assez de boulot à
maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière
à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS
à fragmenter le paquet : économie de CPU ...
C'est déjà moins lourd de repérer et modifier les paquets SYN que de
faire du suivi d'état de connexions TCP, non ?
C'est pour éviter de fragmenter les paquets IP encapsulés ou aussi les
paquets L2TP qui les transportent tant qu'on y est ?
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
Sympa, merci. :) D'après la valeur 1420, je penche pour la seconde
hypothèse.
--
Pascal
Vous pouvez me tutoyer.
Piège à spam : boite-a-spam@plouf.fr.eu.org
Un LNS est un routeur, j'imagine difficilement qu'il ait vocation à intervenir sur les couches réseau au-dessus d'IP (sauf pour des choses comme du filtrage administratif). Il n'a pas déjà assez de boulot à maintenir ses dizaines de tunnels L2TP et ses milliers de sessions PPP ?
Il y a toutefois l'adjust-mss qui réécrit les paquets SYN de manière à ce que les MSS ne dépassent jamais la valeur qui forcerait le LNS à fragmenter le paquet : économie de CPU ...
C'est déjà moins lourd de repérer et modifier les paquets SYN que de faire du suivi d'état de connexions TCP, non ? C'est pour éviter de fragmenter les paquets IP encapsulés ou aussi les paquets L2TP qui les transportent tant qu'on y est ?
Détails des configurations sur http://rencade.raphit.net/config/routeurs/.
Sympa, merci. :) D'après la valeur 1420, je penche pour la seconde hypothèse.
