Je cherche =E0 illustrer un sc=E9nario sorti de mon imaginaire.
Un commercial se trouve dans le hall d'un a=E9rogare. En attendant son
vol, il sort son ordinateur portable, se connecte par WiFi sur l'une
des bornes en service, et souhaite interroger une base de donn=E9es de
son entreprise.
La connection est r=E9alis=E9e par IPsec, avec ESP en mode tunnel.
Je supposerais bien que la pile de protocoles serait la suivante, sur
la liaison hertzienne, dans la phase active d'=E9change de donn=E9es
chiffr=E9es (pas =E0 l'initialisation).
Tout ce qui est au-dessus de ESP est chiffr=E9. Mais quelles
diff=E9rences existerait-il entre les adresses d'IP-1 et IP-2, nous
avons une seule personne avec un ordinateur portable ? Le tunnel
d=E9bute-t-il bien en sortie de ce portable ?
Je serais ravi de lire vos commentaires sur le sujet. Ma pile est
peut-=EAtre totalement fausse.
Cordialement,
Michelot
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
Eric Masson
"Michelot" writes:
'Lut,
Un commercial se trouve dans le hall d'un aérogare. En attendant son vol, il sort son ordinateur portable, se connecte par WiFi sur l'une des bornes en service, et souhaite interroger une base de données de son entreprise.
La connection est réalisée par IPsec, avec ESP en mode tunnel.
Pour que cela ait une chance de fonctionner, il faut déjà que l'opérateur du hotspot wifi ne filtre pas le traffic de façon trop brutale, que le client (portable) utilise une implémentation ipsec qui supporte le NAT-T (udp/500, udp/4500).
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Mais quelles différences existerait-il entre les adresses d'IP-1 et IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Le tunnel débute-t-il bien en sortie de ce portable ?
Le tunnel est établi entre la pile ip du portable (on peut assimiler l'extrémité du tunnel à une pseudo-interface) et celle du rasvpn auquel le dit portable se connecte.
-- Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils avaient tous disparus. On a eu une coupure de courant et les fichiers fantômes sont revenus. Aidez-nous -+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
"Michelot" <mhostettler@voila.fr> writes:
'Lut,
Un commercial se trouve dans le hall d'un aérogare. En attendant son
vol, il sort son ordinateur portable, se connecte par WiFi sur l'une
des bornes en service, et souhaite interroger une base de données de
son entreprise.
La connection est réalisée par IPsec, avec ESP en mode tunnel.
Pour que cela ait une chance de fonctionner, il faut déjà que
l'opérateur du hotspot wifi ne filtre pas le traffic de façon trop
brutale, que le client (portable) utilise une implémentation ipsec qui
supporte le NAT-T (udp/500, udp/4500).
On aurait donc dans ce cas comme seul trafic entre le portable et le
rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames
esp encapsulées dans des paquets udp afin de leur permettre de passer
les NAT des routeurs sur le chemin réseau.
Mais quelles différences existerait-il entre les adresses d'IP-1 et
IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Le tunnel débute-t-il bien en sortie de ce portable ?
Le tunnel est établi entre la pile ip du portable (on peut assimiler
l'extrémité du tunnel à une pseudo-interface) et celle du rasvpn auquel
le dit portable se connecte.
--
Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils
avaient tous disparus. On a eu une coupure de courant et les fichiers
fantômes sont revenus. Aidez-nous
-+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
Un commercial se trouve dans le hall d'un aérogare. En attendant son vol, il sort son ordinateur portable, se connecte par WiFi sur l'une des bornes en service, et souhaite interroger une base de données de son entreprise.
La connection est réalisée par IPsec, avec ESP en mode tunnel.
Pour que cela ait une chance de fonctionner, il faut déjà que l'opérateur du hotspot wifi ne filtre pas le traffic de façon trop brutale, que le client (portable) utilise une implémentation ipsec qui supporte le NAT-T (udp/500, udp/4500).
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Mais quelles différences existerait-il entre les adresses d'IP-1 et IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Le tunnel débute-t-il bien en sortie de ce portable ?
Le tunnel est établi entre la pile ip du portable (on peut assimiler l'extrémité du tunnel à une pseudo-interface) et celle du rasvpn auquel le dit portable se connecte.
-- Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils avaient tous disparus. On a eu une coupure de courant et les fichiers fantômes sont revenus. Aidez-nous -+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
Michelot
Bonjour Eric,
Merci pour votre message.
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela ?
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non l'inverse, OK ?
Mais quelles différences existerait-il entre les adresses d'IP-1 et IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Les datagrammes IP-1 sont encapsulés dans les datagrammes IP-2 par l'intermédiaire de PPP, L2TP, UDP, si on est bien dans la solution L2TP/IPsec.
Nous avons le portable du commercial en source, par conséquent l'adresse source de IP-1 est-elle différente de l'adresse source de IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
Merci pour vos avis, cordialement, Michelot
Bonjour Eric,
Merci pour votre message.
On aurait donc dans ce cas comme seul trafic entre le portable et le
rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames
esp encapsulées dans des paquets udp afin de leur permettre de passer
les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela
?
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non
l'inverse, OK ?
Mais quelles différences existerait-il entre les adresses d'IP-1 et
IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Les datagrammes IP-1 sont encapsulés dans les datagrammes IP-2 par
l'intermédiaire de PPP, L2TP, UDP, si on est bien dans la solution
L2TP/IPsec.
Nous avons le portable du commercial en source, par conséquent
l'adresse source de IP-1 est-elle différente de l'adresse source de
IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela ?
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non l'inverse, OK ?
Mais quelles différences existerait-il entre les adresses d'IP-1 et IP-2, nous avons une seule personne avec un ordinateur portable ?
Quelle est la question exactement ?
Les datagrammes IP-1 sont encapsulés dans les datagrammes IP-2 par l'intermédiaire de PPP, L2TP, UDP, si on est bien dans la solution L2TP/IPsec.
Nous avons le portable du commercial en source, par conséquent l'adresse source de IP-1 est-elle différente de l'adresse source de IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
Merci pour vos avis, cordialement, Michelot
Eric Masson
"Michelot" writes:
'Lut,
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même soumis à une transformation ipsec (en cas de support natt, une réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp, voir les rfc 3715, 3947 et 3948.
Nous avons le portable du commercial en source, par conséquent l'adresse source de IP-1 est-elle différente de l'adresse source de IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
Dans le cadre de l2tp, une interface ppp est créée sur le portable avec son propre domaine d'adressage, donc les paquets encapsulés auront pour adresse source celle d'extrémité de l'interface ppp alors que ceux qui empruntent le chemin réseau mis à disposition par le hotspot auront pour adresse source celle qui aura été attribuée au portable par le hotspot.
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere, cisco) créent aussi une interface virtuelle dont l'adresse est attribuée par le raspvn distant (il est préférable que cette adresse et celle attribuée à l'interface servant à la connexion soient distinctes...)
-- Subject: hors-sujet Etudiant1 de Formatique> c'est quoi ce message!!c'est Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!! -+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
"Michelot" <mhostettler@voila.fr> writes:
'Lut,
On aurait donc dans ce cas comme seul trafic entre le portable et le
rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames
esp encapsulées dans des paquets udp afin de leur permettre de passer
les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même
soumis à une transformation ipsec (en cas de support natt, une
réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non
l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp,
voir les rfc 3715, 3947 et 3948.
Nous avons le portable du commercial en source, par conséquent
l'adresse source de IP-1 est-elle différente de l'adresse source de
IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
Dans le cadre de l2tp, une interface ppp est créée sur le portable avec
son propre domaine d'adressage, donc les paquets encapsulés auront pour
adresse source celle d'extrémité de l'interface ppp alors que ceux qui
empruntent le chemin réseau mis à disposition par le hotspot auront
pour adresse source celle qui aura été attribuée au portable par le
hotspot.
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion
d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere,
cisco) créent aussi une interface virtuelle dont l'adresse est attribuée
par le raspvn distant (il est préférable que cette adresse et celle
attribuée à l'interface servant à la connexion soient distinctes...)
--
Subject: hors-sujet
Etudiant1 de Formatique> c'est quoi ce message!!c'est
Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!!
-+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
On aurait donc dans ce cas comme seul trafic entre le portable et le rasvpn de l'udp, udp/500 pour le trafic isakmp, udp/4500 pour les trames esp encapsulées dans des paquets udp afin de leur permettre de passer les NAT des routeurs sur le chemin réseau.
Ainsi, vous ramenez la solution à celle de L2TP/IPsec, c'est bien cela
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même soumis à une transformation ipsec (en cas de support natt, une réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, non l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp, voir les rfc 3715, 3947 et 3948.
Nous avons le portable du commercial en source, par conséquent l'adresse source de IP-1 est-elle différente de l'adresse source de IP-2, puisque le trafic en sortie de ce portable est L2TP/IPsec.
Dans le cadre de l2tp, une interface ppp est créée sur le portable avec son propre domaine d'adressage, donc les paquets encapsulés auront pour adresse source celle d'extrémité de l'interface ppp alors que ceux qui empruntent le chemin réseau mis à disposition par le hotspot auront pour adresse source celle qui aura été attribuée au portable par le hotspot.
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere, cisco) créent aussi une interface virtuelle dont l'adresse est attribuée par le raspvn distant (il est préférable que cette adresse et celle attribuée à l'interface servant à la connexion soient distinctes...)
-- Subject: hors-sujet Etudiant1 de Formatique> c'est quoi ce message!!c'est Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!! -+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
Michelot
Re-bonjour Eric,
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même soumis à une transformation ipsec (en cas de support natt, une réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, n on l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp, voir les rfc 3715, 3947 et 3948.
Mes connaissances sont crasses dans ce domaine !
Donc, résumons. Pour permettre NATT avec IPsec, on aurait la pile de protocoles suivante :
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere, cisco) créent aussi une interface virtuelle dont l'adresse est attribu ée par le raspvn distant (il est préférable que cette adresse et celle attribuée à l'interface servant à la connexion soient distinctes...)
Je comprend cela. On ouvre un tunnel client entre le portable du commercial et le rasvpn distant, et les adresses source et destination de IP-2 sont celles des extrémités du tunnel client.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entreprise. Et, du point de vue du ou des opérateurs de transport intermédiaires, ce trafic protégé par le client est considéré de la même façon qu'un trafic public.
Cordialement, Michelot
Re-bonjour Eric,
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même
soumis à une transformation ipsec (en cas de support natt, une
réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, n on
l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp,
voir les rfc 3715, 3947 et 3948.
Mes connaissances sont crasses dans ce domaine !
Donc, résumons. Pour permettre NATT avec IPsec, on aurait la pile de
protocoles suivante :
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion
d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere,
cisco) créent aussi une interface virtuelle dont l'adresse est attribu ée
par le raspvn distant (il est préférable que cette adresse et celle
attribuée à l'interface servant à la connexion soient distinctes...)
Je comprend cela. On ouvre un tunnel client entre le portable du
commercial et le rasvpn distant, et les adresses source et destination
de IP-2 sont celles des extrémités du tunnel client.
Ce point est important car le tunnel client ouvert entre le portable et
l'entreprise distante n'implique pas l'existence d'un tunnel opérateur
au sein du réseau de transport du ou des opérateurs grande distance
traversés. L'aérogare peut être situé à 2000 km de l'entreprise.
Et, du point de vue du ou des opérateurs de transport intermédiaires,
ce trafic protégé par le client est considéré de la même façon
qu'un trafic public.
Non, L2TP over Ipsec, c'est du ppp encapsulé dans de l'udp lui même soumis à une transformation ipsec (en cas de support natt, une réencapsulation udp doit probablement intervenir)
Ce devrait être les datagrammes UDP qui sont encapsulés dans ESP, n on l'inverse, OK ?
Non, ipsec NATT, ce sont bien des paquets esp encapsulés dans de l'udp, voir les rfc 3715, 3947 et 3948.
Mes connaissances sont crasses dans ce domaine !
Donc, résumons. Pour permettre NATT avec IPsec, on aurait la pile de protocoles suivante :
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Pour un client ipsec natt sans l2tp, ceux que j'ai eu l'occasion d'utiliser jusqu'à maintenant (ShrewSoft, Nortel, Business Everywhere, cisco) créent aussi une interface virtuelle dont l'adresse est attribu ée par le raspvn distant (il est préférable que cette adresse et celle attribuée à l'interface servant à la connexion soient distinctes...)
Je comprend cela. On ouvre un tunnel client entre le portable du commercial et le rasvpn distant, et les adresses source et destination de IP-2 sont celles des extrémités du tunnel client.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entreprise. Et, du point de vue du ou des opérateurs de transport intermédiaires, ce trafic protégé par le client est considéré de la même façon qu'un trafic public.
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribuée par le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur dhcp du hotspot, alors oui.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entreprise. Et, du point de vue du ou des opérateurs de transport intermédiaires, ce trafic protégé par le client est considéré de la même façon qu'un trafic public.
C'est ce qu'il est.
-- Il est évident que nombre de sites sont censuré à l'inssue de l'utilisateur. Il existe une "black liste" de site chez les fournisseurs et ils font de la sensure sans en avertir les internautes. -+- DM in : <http://www.le-gnu.net> - FAI sournois avec le neuneu -+-
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribuée par
le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur
dhcp du hotspot, alors oui.
Ce point est important car le tunnel client ouvert entre le portable et
l'entreprise distante n'implique pas l'existence d'un tunnel opérateur
au sein du réseau de transport du ou des opérateurs grande distance
traversés. L'aérogare peut être situé à 2000 km de l'entreprise.
Et, du point de vue du ou des opérateurs de transport intermédiaires,
ce trafic protégé par le client est considéré de la même façon
qu'un trafic public.
C'est ce qu'il est.
--
Il est évident que nombre de sites sont censuré à l'inssue de
l'utilisateur. Il existe une "black liste" de site chez les fournisseurs
et ils font de la sensure sans en avertir les internautes.
-+- DM in : <http://www.le-gnu.net> - FAI sournois avec le neuneu -+-
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribuée par le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur dhcp du hotspot, alors oui.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entreprise. Et, du point de vue du ou des opérateurs de transport intermédiaires, ce trafic protégé par le client est considéré de la même façon qu'un trafic public.
C'est ce qu'il est.
-- Il est évident que nombre de sites sont censuré à l'inssue de l'utilisateur. Il existe une "black liste" de site chez les fournisseurs et ils font de la sensure sans en avertir les internautes. -+- DM in : <http://www.le-gnu.net> - FAI sournois avec le neuneu -+-
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribu ée par le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur dhcp du hotspot, alors oui.
Il ne faut pas que j'inverse.
Dans IP1 on trouve les adresses attribuées par les rasvpn aux extrémités du tunnel, et dans IP2 on trouve les adresses de la connexion de bout en bout.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entrepri se. Et, du point de vue du ou des opérateurs de transport intermédiaire s, ce trafic protégé par le client est considéré de la même fa çon qu'un trafic public.
C'est ce qu'il est.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu. Dans ce cas, la connection IPsec ne passe pas par ces pays ou, encore, elle est déchiffrée pour être rechiffrée en sortie des AS impliquées.
Selon la législation du pays, le contenu de l'information client n'est parfois pas transparent pour l'opérateur. Et ce contenu doit être rendu lisible pour une écoute officielle, en règle.
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribu ée par
le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur
dhcp du hotspot, alors oui.
Il ne faut pas que j'inverse.
Dans IP1 on trouve les adresses attribuées par les rasvpn aux
extrémités du tunnel, et dans IP2 on trouve les adresses de la
connexion de bout en bout.
Ce point est important car le tunnel client ouvert entre le portable et
l'entreprise distante n'implique pas l'existence d'un tunnel opérateur
au sein du réseau de transport du ou des opérateurs grande distance
traversés. L'aérogare peut être situé à 2000 km de l'entrepri se.
Et, du point de vue du ou des opérateurs de transport intermédiaire s,
ce trafic protégé par le client est considéré de la même fa çon
qu'un trafic public.
C'est ce qu'il est.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité
n'a pas la même implication que chez nous, le chiffrement du client
est contrôlé : soit il est interdit, soit la taille de la clé est
réduite afin que les autorités gouvernementales puissent observer le
contenu. Dans ce cas, la connection IPsec ne passe pas par ces pays ou,
encore, elle est déchiffrée pour être rechiffrée en sortie des AS
impliquées.
Selon la législation du pays, le contenu de l'information client n'est
parfois pas transparent pour l'opérateur. Et ce contenu doit être
rendu lisible pour une écoute officielle, en règle.
Cela vous aparait-il correct, et conforme à ce que vous connaissez ?
Si tu te réfères au portable, que ip1 est l'adresse privée attribu ée par le rasvpn et que ip2 est l'adresse attribuée au portable par le serveur dhcp du hotspot, alors oui.
Il ne faut pas que j'inverse.
Dans IP1 on trouve les adresses attribuées par les rasvpn aux extrémités du tunnel, et dans IP2 on trouve les adresses de la connexion de bout en bout.
Ce point est important car le tunnel client ouvert entre le portable et l'entreprise distante n'implique pas l'existence d'un tunnel opérateur au sein du réseau de transport du ou des opérateurs grande distance traversés. L'aérogare peut être situé à 2000 km de l'entrepri se. Et, du point de vue du ou des opérateurs de transport intermédiaire s, ce trafic protégé par le client est considéré de la même fa çon qu'un trafic public.
C'est ce qu'il est.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu. Dans ce cas, la connection IPsec ne passe pas par ces pays ou, encore, elle est déchiffrée pour être rechiffrée en sortie des AS impliquées.
Selon la législation du pays, le contenu de l'information client n'est parfois pas transparent pour l'opérateur. Et ce contenu doit être rendu lisible pour une écoute officielle, en règle.
Cordialement, Michelot
Eric Masson
"Michelot" writes:
'Lut,
Dans IP1 on trouve les adresses attribuées par les rasvpn aux extrémités du tunnel, et dans IP2 on trouve les adresses de la connexion de bout en bout.
Correct.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la législation était majoritairement foulée au pied.
-- J'aime bien les titres ronflants. Mais si vous proposez la place de Grand Manitou Intranet/Internet, Sommité du HTML, Maître Incontesté du Java, j'envisagerai votre proposition avec plus d'intérêt. -+- MS In <http://www.le-gnu.net> : Testons modestes et pondérés -+-
"Michelot" <mhostettler@voila.fr> writes:
'Lut,
Dans IP1 on trouve les adresses attribuées par les rasvpn aux
extrémités du tunnel, et dans IP2 on trouve les adresses de la
connexion de bout en bout.
Correct.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité
n'a pas la même implication que chez nous, le chiffrement du client
est contrôlé : soit il est interdit, soit la taille de la clé est
réduite afin que les autorités gouvernementales puissent observer le
contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la
législation était majoritairement foulée au pied.
--
J'aime bien les titres ronflants. Mais si vous proposez la place de
Grand Manitou Intranet/Internet, Sommité du HTML, Maître Incontesté du
Java, j'envisagerai votre proposition avec plus d'intérêt.
-+- MS In <http://www.le-gnu.net> : Testons modestes et pondérés -+-
Dans IP1 on trouve les adresses attribuées par les rasvpn aux extrémités du tunnel, et dans IP2 on trouve les adresses de la connexion de bout en bout.
Correct.
Complétons d'ailleurs ce point. Dans certains pays où la sécurité n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la législation était majoritairement foulée au pied.
-- J'aime bien les titres ronflants. Mais si vous proposez la place de Grand Manitou Intranet/Internet, Sommité du HTML, Maître Incontesté du Java, j'envisagerai votre proposition avec plus d'intérêt. -+- MS In <http://www.le-gnu.net> : Testons modestes et pondérés -+-
Michelot
Bonjour Eric,
Complétons d'ailleurs ce point. Dans certains pays où la sécurit é n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la législation était majoritairement foulée au pied.
Exact, pour la France, la liberté de cryptologie constitue le 1er alinéa de l'article 30 de la loi LCEN du 21 juin 2004.
Néanmoins, je ne sais pas si le décret est paru. Quelqu'un a-t-il l'information ?
Pour mémoire, la précédente loi sur le sujet datait du 30 décembre 1990 avec un décret paru près de 9 ans plus tard, le 17 mars 1999, lequel stipulait que la clé de chiffrement ne devait pas dépasser 128 bits.
Cordialement, Michelot
Bonjour Eric,
Complétons d'ailleurs ce point. Dans certains pays où la sécurit é
n'a pas la même implication que chez nous, le chiffrement du client
est contrôlé : soit il est interdit, soit la taille de la clé est
réduite afin que les autorités gouvernementales puissent observer le
contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la
législation était majoritairement foulée au pied.
Exact, pour la France, la liberté de cryptologie constitue le 1er
alinéa de l'article 30 de la loi LCEN du 21 juin 2004.
Néanmoins, je ne sais pas si le décret est paru. Quelqu'un a-t-il
l'information ?
Pour mémoire, la précédente loi sur le sujet datait du 30 décembre
1990 avec un décret paru près de 9 ans plus tard, le 17 mars 1999,
lequel stipulait que la clé de chiffrement ne devait pas dépasser 128
bits.
Complétons d'ailleurs ce point. Dans certains pays où la sécurit é n'a pas la même implication que chez nous, le chiffrement du client est contrôlé : soit il est interdit, soit la taille de la clé est réduite afin que les autorités gouvernementales puissent observer le contenu.
C'était officiellement encore le cas il y a peu en France, mais bon, la législation était majoritairement foulée au pied.
Exact, pour la France, la liberté de cryptologie constitue le 1er alinéa de l'article 30 de la loi LCEN du 21 juin 2004.
Néanmoins, je ne sais pas si le décret est paru. Quelqu'un a-t-il l'information ?
Pour mémoire, la précédente loi sur le sujet datait du 30 décembre 1990 avec un décret paru près de 9 ans plus tard, le 17 mars 1999, lequel stipulait que la clé de chiffrement ne devait pas dépasser 128 bits.
