Dans le cadre d'un projet d'études (Master1 en informatique,
anciennement maîtrise), je dois contruire un programme se greffant au
dessus d'un VPN, permettant de transmettre notamment l'ARP, le DHCP,
IP-broadcast, IPX, etc...
Les questions qui se posent encore sont conceptuelles et concernent
l'encapsulation (le sniffage et la re-injection semblent résolues, idem
pour l'architecture générale du programme).
plusieurs solutinos ont été envisagées, et je n'ai pas l'expérience
requise pour décider de la meilleure.
1) intuitivement, j'utilise entre chaque passerelle du VPN des
connections TCP, qui transportent les paquets sniffés précédés d'un
champ de taille (16bits) et d'un champ de protocole encapsulé (16bit).
L'inconvenient me semble être que sur de grand VPN, un grand nombre de
connexions vont être ouvertes.
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en
introduisant un champ supplémentaire de sequencement des paquets. Peu de
sockets ouvertes (une par passerelle) mais des paquets sont perdus et je
dois les injecter dans le bon ordre.
3) Il existe des protocoles d'encapsulation déjà très bien fait mais je
trouve la documentation à leur sujet assez pauvre. Je pense à GRE, mais
je n'ai aucune information certaine à son sujet:
-> la gestion de GRE par le noyau me livre-t-elle son contenu
ré-ordonné?
-> GRE ne porte pas de numero de ports émetteur/récepteur. Peu pratique
quand on réalise un programme à base de sockets classiques
-> GRE ne semble pas porter de champ ACK/NACK. Est-il fiable?
-> La réponse à ces questions dépend-elle de l'utilisation sous-jacente
d'un tunnel (PPTP, IPsec, ...)? on programme devrait ouvoir fonctionner
sans trop avoir à se soucier du VPN en dessous (soit en étant facilement
configurable, soit en étant générique au possible). La solution TCP
retenue me semble jouerla carte de la généricité, mais pas celle de la
performance.
MErci pour toute l'information que vous pourrez m'apporter, que ce soit
par des liens ou vos expériences personnelles.
Jean-Francois Smigielski
-- ENGLISH VERSION ---------------------------------------------
Hello world,
I need to build an "add-on" for VPN's. Please let me explain the context
and you too will feel it very clear.
The goal is to provide support for ARP, IP-broadcast, IPX, etc... over a
VPN. I don't worry about the way the tranport is done and securized, I
just have to build a program (both client/server) that capture the target
packets and send them to his peers on the other on the VPN. The packets
are then released on the right interface.
I solved all my technical/programming problems, now just remain some
conceptual leaks. I have full freedom of choice for encapsulation. I just
have to ensure that packets sniffed in a certain order (don't necessarily
arrive in this order but) are released in this precise order.
Several solutions are possible:
1) use a TCP stream and find a (personnal) way to delimitate and identify
incomming messages. This solution has a "scaling" problem. Large VPN will
require many TCP connections
2) use UDP and provide the possibility to re-order and identify the
messages. As a drawback, I mention that large VPN may cause significant
packet losses. (But only one listening socket seems enough)
3) use something else, my toughts go to GRE.
GRE has in its headers all the informations I need, but I don't have any
certified information about the GRE RELIABILITY:
-> A GRE-header doesn't have any ACK/NACK field, I suppose it's
unreliable. Is it True?
-> A GRE-header may contains a sequence number, but do I have to handle
the re-ordering by myself?
-> A GRE-header contains no port numbers. Arghhh! that's not fine if GRE
packets arrive from the internet. I have to retrieve incoming messages
form the internet with a common socket...
My preferred solution would be to use TCP and add two 16bit informations
fields (one for the protocol encapsulated, and one for the length of the
encapsulated packet), just because the re-ordering seems to be hard to
perform. Scalability will be a future concern...
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
Jacques Caron
Salut,
On Sat, 16 Apr 2005 13:34:19 +0200, Jean-Francois Smigielski wrote:
Dans le cadre d'un projet d'études (Master1 en informatique, anciennement maîtrise), je dois contruire un programme se greffant au dessus d'un VPN, permettant de transmettre notamment l'ARP, le DHCP, IP-broadcast, IPX, etc...
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement encapsuler de l'Ethernet (et bridger), soit faire une encapsulation multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas forcément utiles.
1) intuitivement, j'utilise entre chaque passerelle du VPN des connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont reliés directement l'un à l'autre) ou hup and spoke (en étoile).
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont perdus et je dois les injecter dans le bon ordre.
Pourquoi?
3) Il existe des protocoles d'encapsulation déjà très bien fait mais je trouve la documentation à leur sujet assez pauvre.
Il y a pourtant de RFC kilométriques pour certains d'entre eux, des sites web entiers pour d'autres, et des tonnes de sources pour la plupart.
Je pense à GRE, mais je n'ai aucune information certaine à son sujet:
-> la gestion de GRE par le noyau me livre-t-elle son contenu ré-ordonné?
Non, pour quoi faire?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
Peu pratique quand on réalise un programme à base de sockets classiques
SOCK_RAW est fait pour ça.
-> GRE ne semble pas porter de champ ACK/NACK. Est-il fiable?
Non, et c'est normal, ce sont aux protocoles de plus haut niveau (TCP essentiellement) d'assurer cette tâche. Certains protocoles utilisent explicitement UDP parce qu'ils s'attachent plus à l'absence de délais qu'à la fiabilité (ça concerne surtout tout ce qui est streaming, et en particulier la voix et la vidéo sur IP). Imposer des retransmissions à un plus bas niveau alors qu'ils n'en veulent pas n'est pas une bonne idée.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Dans le cadre d'un projet d'études (Master1 en informatique,
anciennement maîtrise), je dois contruire un programme se greffant au
dessus d'un VPN, permettant de transmettre notamment l'ARP, le DHCP,
IP-broadcast, IPX, etc...
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement
encapsuler de l'Ethernet (et bridger), soit faire une encapsulation
multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas
forcément utiles.
1) intuitivement, j'utilise entre chaque passerelle du VPN des
connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer
de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de
connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont
reliés directement l'un à l'autre) ou hup and spoke (en étoile).
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en
introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont perdus
et je dois les injecter dans le bon ordre.
Pourquoi?
3) Il existe des protocoles d'encapsulation déjà très bien fait mais je
trouve la documentation à leur sujet assez pauvre.
Il y a pourtant de RFC kilométriques pour certains d'entre eux, des sites
web entiers pour d'autres, et des tonnes de sources pour la plupart.
Je pense à GRE, mais je n'ai aucune information certaine à son sujet:
-> la gestion de GRE par le noyau me livre-t-elle son contenu
ré-ordonné?
Non, pour quoi faire?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
Peu pratique quand on réalise un programme à base de sockets classiques
SOCK_RAW est fait pour ça.
-> GRE ne semble pas porter de champ ACK/NACK. Est-il fiable?
Non, et c'est normal, ce sont aux protocoles de plus haut niveau (TCP
essentiellement) d'assurer cette tâche. Certains protocoles utilisent
explicitement UDP parce qu'ils s'attachent plus à l'absence de délais qu'à
la fiabilité (ça concerne surtout tout ce qui est streaming, et en
particulier la voix et la vidéo sur IP). Imposer des retransmissions à un
plus bas niveau alors qu'ils n'en veulent pas n'est pas une bonne idée.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Sat, 16 Apr 2005 13:34:19 +0200, Jean-Francois Smigielski wrote:
Dans le cadre d'un projet d'études (Master1 en informatique, anciennement maîtrise), je dois contruire un programme se greffant au dessus d'un VPN, permettant de transmettre notamment l'ARP, le DHCP, IP-broadcast, IPX, etc...
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement encapsuler de l'Ethernet (et bridger), soit faire une encapsulation multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas forcément utiles.
1) intuitivement, j'utilise entre chaque passerelle du VPN des connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont reliés directement l'un à l'autre) ou hup and spoke (en étoile).
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont perdus et je dois les injecter dans le bon ordre.
Pourquoi?
3) Il existe des protocoles d'encapsulation déjà très bien fait mais je trouve la documentation à leur sujet assez pauvre.
Il y a pourtant de RFC kilométriques pour certains d'entre eux, des sites web entiers pour d'autres, et des tonnes de sources pour la plupart.
Je pense à GRE, mais je n'ai aucune information certaine à son sujet:
-> la gestion de GRE par le noyau me livre-t-elle son contenu ré-ordonné?
Non, pour quoi faire?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
Peu pratique quand on réalise un programme à base de sockets classiques
SOCK_RAW est fait pour ça.
-> GRE ne semble pas porter de champ ACK/NACK. Est-il fiable?
Non, et c'est normal, ce sont aux protocoles de plus haut niveau (TCP essentiellement) d'assurer cette tâche. Certains protocoles utilisent explicitement UDP parce qu'ils s'attachent plus à l'absence de délais qu'à la fiabilité (ça concerne surtout tout ce qui est streaming, et en particulier la voix et la vidéo sur IP). Imposer des retransmissions à un plus bas niveau alors qu'ils n'en veulent pas n'est pas une bonne idée.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jean-Francois Smigielski
MErci beaucoup de m'avoir répondu. Ca fait plaisir.
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement encapsuler de l'Ethernet (et bridger), soit faire une encapsulation multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas forcément utiles.
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du programme en cours de développement (ce n'est pas moi qui l'ai choisi, mais le responsable du projet, et en bon étudiant je fais ce qu'on me dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans l'ordre, sont: * IP broadcast (IP unicast est déjà géré) * ARP * IPX * ... et plus si affinités! Bien que nous ne transportions pas tout l'ethernet, nous devons laisser l'encapsulation ethernet initiale pour la relacher en l'état et conserver une transparence totale. (nécessaire à l'ARP, je pense)
Et puis il y a aussi un problème cruel: ce que j'injecte sur une interface ne doit pas être re-sniffé et renvoyé. Nous devons être capable de l'identifer afin de ne pas créer de boucles. Ceci est déjà réalisé en hachant seulement des parties significatives des messages, car le hachage de toutes les données est trop couteux en temps de calcul. Il est nécessaire pour cela de connaître le protocole de niveau 3 qui est véhiculé.
1) intuitivement, j'utilise entre chaque passerelle du VPN des connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont reliés directement l'un à l'autre) ou hup and spoke (en étoile).
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec, je dirais "Full mesh".
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont perdus et je dois les injecter dans le bon ordre.
Pourquoi?
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS. Et là les paquets arrivent quand même ordonnés, non?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Peu pratique quand on réalise un programme à base de sockets classiques
SOCK_RAW est fait pour ça.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les communications de bas niveau, des concepts m'echappent encore). Mais tous les paquets GRE ne sont ps forcément destinés à cette application. C'est justement pour éluder toutes ces questions que je proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant un moyen de retrouver le type de contenu. Je profite ainsi des checksum sur le payload fait par UDP...
En tous cas, merci de m'avoir répondu si précisément, ça aura fait beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir que l'ordre des paquets n'est pas important).
Jean-Francois Smigielski
MErci beaucoup de m'avoir répondu. Ca fait plaisir.
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement
encapsuler de l'Ethernet (et bridger), soit faire une encapsulation
multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas
forcément utiles.
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du
programme en cours de développement (ce n'est pas moi qui l'ai choisi,
mais le responsable du projet, et en bon étudiant je fais ce qu'on me
dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être
véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans
l'ordre, sont:
* IP broadcast (IP unicast est déjà géré)
* ARP
* IPX
* ... et plus si affinités!
Bien que nous ne transportions pas tout l'ethernet, nous devons laisser
l'encapsulation ethernet initiale pour la relacher en l'état et
conserver une transparence totale. (nécessaire à l'ARP, je pense)
Et puis il y a aussi un problème cruel: ce que j'injecte sur une
interface ne doit pas être re-sniffé et renvoyé. Nous devons être
capable de l'identifer afin de ne pas créer de boucles.
Ceci est déjà réalisé en hachant seulement des parties significatives
des messages, car le hachage de toutes les données est trop couteux en
temps de calcul. Il est nécessaire pour cela de connaître le protocole
de niveau 3 qui est véhiculé.
1) intuitivement, j'utilise entre chaque passerelle du VPN des
connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer
de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de
connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont
reliés directement l'un à l'autre) ou hup and spoke (en étoile).
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec,
je dirais "Full mesh".
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en
introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont
perdus et je dois les injecter dans le bon ordre.
Pourquoi?
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le
début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je
dois simuler de manière transparente une communication sur un BUS. Et là
les paquets arrivent quand même ordonnés, non?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de
niveau 4, non?
Peu pratique quand on réalise un programme à base de sockets
classiques
SOCK_RAW est fait pour ça.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je
vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les
communications de bas niveau, des concepts m'echappent encore).
Mais tous les paquets GRE ne sont ps forcément destinés à cette
application.
C'est justement pour éluder toutes ces questions que je
proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant
un moyen de retrouver le type de contenu. Je profite ainsi des checksum
sur le payload fait par UDP...
En tous cas, merci de m'avoir répondu si précisément, ça aura fait
beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir
que l'ordre des paquets n'est pas important).
MErci beaucoup de m'avoir répondu. Ca fait plaisir.
Bref, de l'ARP, de l'IP, de l'IPX, etc. Tu peux donc soit bêtement encapsuler de l'Ethernet (et bridger), soit faire une encapsulation multi-protocoles, mais dans ce cas ARP et DHCP ne me paraissent pas forcément utiles.
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du programme en cours de développement (ce n'est pas moi qui l'ai choisi, mais le responsable du projet, et en bon étudiant je fais ce qu'on me dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans l'ordre, sont: * IP broadcast (IP unicast est déjà géré) * ARP * IPX * ... et plus si affinités! Bien que nous ne transportions pas tout l'ethernet, nous devons laisser l'encapsulation ethernet initiale pour la relacher en l'état et conserver une transparence totale. (nécessaire à l'ARP, je pense)
Et puis il y a aussi un problème cruel: ce que j'injecte sur une interface ne doit pas être re-sniffé et renvoyé. Nous devons être capable de l'identifer afin de ne pas créer de boucles. Ceci est déjà réalisé en hachant seulement des parties significatives des messages, car le hachage de toutes les données est trop couteux en temps de calcul. Il est nécessaire pour cela de connaître le protocole de niveau 3 qui est véhiculé.
1) intuitivement, j'utilise entre chaque passerelle du VPN des connections TCP,
TCP pour un VPN ce n'est généralement pas une bonne idée. Il faut préférer de l'UDP ou de l'IP "pur".
L'inconvenient me semble être que sur de grand VPN, un grand nombre de connexions vont être ouvertes.
Tout dépend de l'architecture du VPN: full mesh (tous les réseaux sont reliés directement l'un à l'autre) ou hup and spoke (en étoile).
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec, je dirais "Full mesh".
2) il est aussi possible d'utiliser le même mécanisme pour UDP, mais en introduisant un champ supplémentaire de sequencement des paquets.
Pour quoi faire?
Peu de sockets ouvertes (une par passerelle) mais des paquets sont perdus et je dois les injecter dans le bon ordre.
Pourquoi?
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS. Et là les paquets arrivent quand même ordonnés, non?
-> GRE ne porte pas de numero de ports émetteur/récepteur.
Normal, c'est un protocole IP directement.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Peu pratique quand on réalise un programme à base de sockets classiques
SOCK_RAW est fait pour ça.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les communications de bas niveau, des concepts m'echappent encore). Mais tous les paquets GRE ne sont ps forcément destinés à cette application. C'est justement pour éluder toutes ces questions que je proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant un moyen de retrouver le type de contenu. Je profite ainsi des checksum sur le payload fait par UDP...
En tous cas, merci de m'avoir répondu si précisément, ça aura fait beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir que l'ordre des paquets n'est pas important).
Jean-Francois Smigielski
Jacques Caron
Salut,
On Wed, 20 Apr 2005 15:26:55 +0200, Jean-Francois Smigielski wrote:
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du programme en cours de développement (ce n'est pas moi qui l'ai choisi, mais le responsable du projet, et en bon étudiant je fais ce qu'on me dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans l'ordre, sont: * IP broadcast (IP unicast est déjà géré) * ARP * IPX * ... et plus si affinités!
Le fait de ne pas encapsuler toute la trame Ethernet est une contrainte imposée ou une déduction? Dans le deuxième cas, je ne vois pas bien comment tu y arrives. Et ça ne sert à rien de transporter ARP si les deux bouts du VPN ne forment pas un réseau niveau 2 unique (ARP n'est utile qu'on sein d'un même réseau niveau 2), donc j'aurais tendance à dire que si les données du problème sont "il faut transporter ARP", pour moi ça signifie "le VPN doit apparaître comme un pont niveau 2". Donc encapsulation complète des trames Ethernet dans des paquets IP ou UDP.
Si on ne transporte pas toute la trame Ethernet, alors ARP ne sert à rien (et vraisemblablement DHCP non plus, mais ça peut être plus subtil), sauf éventuellement si le VPN est fully meshed et considéré comme un réseau L2 à lui tout seul, et qu'on a une forme de broadcast sur ce réseau, et qu'on attribue des adresses MAC à chaque extrémité du VPN, et qu'on n'a pas d'autre moyen de faire la correspondance IP -> MAC (donc IP -> tunnel). Mais ça fait beaucoup de conditions, et ça me paraîtrait complètement idiot, ou alors j'ai raté un épisode.
Bien que nous ne transportions pas tout l'ethernet, nous devons laisser l'encapsulation ethernet initiale pour la relacher en l'état et conserver une transparence totale. (nécessaire à l'ARP, je pense)
Là, je ne comprends plus. Tu ne transportes pas toute la trame Ethernet mais tu gardes l'encapsulation Ethernet? Quelle est la différence?
Et puis il y a aussi un problème cruel: ce que j'injecte sur une interface ne doit pas être re-sniffé et renvoyé.
J'avoue que je ne suis pas convaincu que "sniffer" soit la bonne méthode, mais bon, ça c'est vraiment un détail d'implémentation.
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec, je dirais "Full mesh".
Je ne vois pas le lien de cause à effet...
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS. Et là les paquets arrivent quand même ordonnés, non?
Oui, mais rien ne garantit qu'ils arrivent. Des retransmissions à un niveau supérieur sont donc nécessaires, et par conséquent les paquets n'arrivent pas forcément dans l'ordre initial.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Quel protocole de niveau 3? GRE est relativement générique et pourrait être transporté dans à peu près n'importe quel protocole (c'est le but), mais les seules encapsulations définies sont IPv4 dans GRE dans IPv4. Pas de protocol de niveau 3 en vue.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les communications de bas niveau, des concepts m'echappent encore). Mais tous les paquets GRE ne sont ps forcément destinés à cette application.
GRE étant basé sur IP, il n'y a pas de discriminateur de multiplexage comme les ports TCP ou UDP. Il faut donc utiliser les adresses IP source et éventuellement destination (du paquet IPv4 "extérieur") pour savoir s'il s'agit d'un tunnel connu par ton application ou pas (et trouver quel tunnel, éventuellement).
C'est justement pour éluder toutes ces questions que je proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant un moyen de retrouver le type de contenu. Je profite ainsi des checksum sur le payload fait par UDP...
IP et GRE font des checksums eux aussi.
En tous cas, merci de m'avoir répondu si précisément, ça aura fait beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir que l'ordre des paquets n'est pas important).
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du
programme en cours de développement (ce n'est pas moi qui l'ai choisi,
mais le responsable du projet, et en bon étudiant je fais ce qu'on me
dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être
véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans
l'ordre, sont:
* IP broadcast (IP unicast est déjà géré)
* ARP
* IPX
* ... et plus si affinités!
Le fait de ne pas encapsuler toute la trame Ethernet est une contrainte
imposée ou une déduction? Dans le deuxième cas, je ne vois pas bien
comment tu y arrives. Et ça ne sert à rien de transporter ARP si les deux
bouts du VPN ne forment pas un réseau niveau 2 unique (ARP n'est utile
qu'on sein d'un même réseau niveau 2), donc j'aurais tendance à dire que
si les données du problème sont "il faut transporter ARP", pour moi ça
signifie "le VPN doit apparaître comme un pont niveau 2". Donc
encapsulation complète des trames Ethernet dans des paquets IP ou UDP.
Si on ne transporte pas toute la trame Ethernet, alors ARP ne sert à rien
(et vraisemblablement DHCP non plus, mais ça peut être plus subtil), sauf
éventuellement si le VPN est fully meshed et considéré comme un réseau L2
à lui tout seul, et qu'on a une forme de broadcast sur ce réseau, et qu'on
attribue des adresses MAC à chaque extrémité du VPN, et qu'on n'a pas
d'autre moyen de faire la correspondance IP -> MAC (donc IP -> tunnel).
Mais ça fait beaucoup de conditions, et ça me paraîtrait complètement
idiot, ou alors j'ai raté un épisode.
Bien que nous ne transportions pas tout l'ethernet, nous devons laisser
l'encapsulation ethernet initiale pour la relacher en l'état et
conserver une transparence totale. (nécessaire à l'ARP, je pense)
Là, je ne comprends plus. Tu ne transportes pas toute la trame Ethernet
mais tu gardes l'encapsulation Ethernet? Quelle est la différence?
Et puis il y a aussi un problème cruel: ce que j'injecte sur une
interface ne doit pas être re-sniffé et renvoyé.
J'avoue que je ne suis pas convaincu que "sniffer" soit la bonne méthode,
mais bon, ça c'est vraiment un détail d'implémentation.
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec,
je dirais "Full mesh".
Je ne vois pas le lien de cause à effet...
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le
début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je
dois simuler de manière transparente une communication sur un BUS. Et là
les paquets arrivent quand même ordonnés, non?
Oui, mais rien ne garantit qu'ils arrivent. Des retransmissions à un
niveau supérieur sont donc nécessaires, et par conséquent les paquets
n'arrivent pas forcément dans l'ordre initial.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de
niveau 4, non?
Quel protocole de niveau 3? GRE est relativement générique et pourrait
être transporté dans à peu près n'importe quel protocole (c'est le but),
mais les seules encapsulations définies sont IPv4 dans GRE dans IPv4. Pas
de protocol de niveau 3 en vue.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je
vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les
communications de bas niveau, des concepts m'echappent encore).
Mais tous les paquets GRE ne sont ps forcément destinés à cette
application.
GRE étant basé sur IP, il n'y a pas de discriminateur de multiplexage
comme les ports TCP ou UDP. Il faut donc utiliser les adresses IP source
et éventuellement destination (du paquet IPv4 "extérieur") pour savoir
s'il s'agit d'un tunnel connu par ton application ou pas (et trouver quel
tunnel, éventuellement).
C'est justement pour éluder toutes ces questions que je
proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant
un moyen de retrouver le type de contenu. Je profite ainsi des checksum
sur le payload fait par UDP...
IP et GRE font des checksums eux aussi.
En tous cas, merci de m'avoir répondu si précisément, ça aura fait
beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir
que l'ordre des paquets n'est pas important).
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Wed, 20 Apr 2005 15:26:55 +0200, Jean-Francois Smigielski wrote:
Non, l'encapsulation de tout l'ethernet n'est pas souhaitable. Le but du programme en cours de développement (ce n'est pas moi qui l'ai choisi, mais le responsable du projet, et en bon étudiant je fais ce qu'on me dit...) est de permettre à des protocoles (niveaux 3) inhabituels d'être véhiculés au dessus de VPN IP déjà en place. Les objectifs, dans l'ordre, sont: * IP broadcast (IP unicast est déjà géré) * ARP * IPX * ... et plus si affinités!
Le fait de ne pas encapsuler toute la trame Ethernet est une contrainte imposée ou une déduction? Dans le deuxième cas, je ne vois pas bien comment tu y arrives. Et ça ne sert à rien de transporter ARP si les deux bouts du VPN ne forment pas un réseau niveau 2 unique (ARP n'est utile qu'on sein d'un même réseau niveau 2), donc j'aurais tendance à dire que si les données du problème sont "il faut transporter ARP", pour moi ça signifie "le VPN doit apparaître comme un pont niveau 2". Donc encapsulation complète des trames Ethernet dans des paquets IP ou UDP.
Si on ne transporte pas toute la trame Ethernet, alors ARP ne sert à rien (et vraisemblablement DHCP non plus, mais ça peut être plus subtil), sauf éventuellement si le VPN est fully meshed et considéré comme un réseau L2 à lui tout seul, et qu'on a une forme de broadcast sur ce réseau, et qu'on attribue des adresses MAC à chaque extrémité du VPN, et qu'on n'a pas d'autre moyen de faire la correspondance IP -> MAC (donc IP -> tunnel). Mais ça fait beaucoup de conditions, et ça me paraîtrait complètement idiot, ou alors j'ai raté un épisode.
Bien que nous ne transportions pas tout l'ethernet, nous devons laisser l'encapsulation ethernet initiale pour la relacher en l'état et conserver une transparence totale. (nécessaire à l'ARP, je pense)
Là, je ne comprends plus. Tu ne transportes pas toute la trame Ethernet mais tu gardes l'encapsulation Ethernet? Quelle est la différence?
Et puis il y a aussi un problème cruel: ce que j'injecte sur une interface ne doit pas être re-sniffé et renvoyé.
J'avoue que je ne suis pas convaincu que "sniffer" soit la bonne méthode, mais bon, ça c'est vraiment un détail d'implémentation.
Etant donné que le VPN sur lequel nous nous basons est au dessus d'IPsec, je dirais "Full mesh".
Je ne vois pas le lien de cause à effet...
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS. Et là les paquets arrivent quand même ordonnés, non?
Oui, mais rien ne garantit qu'ils arrivent. Des retransmissions à un niveau supérieur sont donc nécessaires, et par conséquent les paquets n'arrivent pas forcément dans l'ordre initial.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Quel protocole de niveau 3? GRE est relativement générique et pourrait être transporté dans à peu près n'importe quel protocole (c'est le but), mais les seules encapsulations définies sont IPv4 dans GRE dans IPv4. Pas de protocol de niveau 3 en vue.
Si j'écoute les paquets GRE depuis une socket ouverte avec SOCK_RAW, je vais choper tout le GRE qui passe, il me semble... (j'avoue qu'avec les communications de bas niveau, des concepts m'echappent encore). Mais tous les paquets GRE ne sont ps forcément destinés à cette application.
GRE étant basé sur IP, il n'y a pas de discriminateur de multiplexage comme les ports TCP ou UDP. Il faut donc utiliser les adresses IP source et éventuellement destination (du paquet IPv4 "extérieur") pour savoir s'il s'agit d'un tunnel connu par ton application ou pas (et trouver quel tunnel, éventuellement).
C'est justement pour éluder toutes ces questions que je proposais d'encapsuler mes données dans UDP (SOCK_DGRAM), en y ajoutant un moyen de retrouver le type de contenu. Je profite ainsi des checksum sur le payload fait par UDP...
IP et GRE font des checksums eux aussi.
En tous cas, merci de m'avoir répondu si précisément, ça aura fait beaucoup avancer les choses (et ça fait un avis dans mon sens, à savoir que l'ordre des paquets n'est pas important).
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Pascal
Salut,
On Wed, 20 Apr 2005 15:26:55 +0200, Jean-Francois Smigielski wrote:
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS.
C'est du pontage ethernet, il faut donc transporter l'encapsulation ethernet.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Non. La couche d'un protocole est définie par les services qu'il fournit à la couche supérieure, pas par la couche inférieure sur laquelle il s'appuie + 1. Autrement, on ne s'en sortirait pas. Ainsi PPP est toujours un protocole de niveau 2 même lorsqu'il est transporté dans L2TP sur UDP sur IP ou dans PPPoE sur ethernet. GRE est un protocole de niveau 2 puisqu'il offre un service de niveau 2 (liaison).
les seules encapsulations définies sont IPv4 dans GRE dans IPv4.
Quid de PPP dans GRE utilisé par le protocole PPTP ?
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le
début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je
dois simuler de manière transparente une communication sur un BUS.
C'est du pontage ethernet, il faut donc transporter l'encapsulation ethernet.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de
niveau 4, non?
Non. La couche d'un protocole est définie par les services qu'il fournit
à la couche supérieure, pas par la couche inférieure sur laquelle il
s'appuie + 1. Autrement, on ne s'en sortirait pas. Ainsi PPP est toujours
un protocole de niveau 2 même lorsqu'il est transporté dans L2TP sur UDP
sur IP ou dans PPPoE sur ethernet. GRE est un protocole de niveau 2
puisqu'il offre un service de niveau 2 (liaison).
les seules encapsulations définies sont IPv4 dans GRE dans IPv4.
Quid de PPP dans GRE utilisé par le protocole PPTP ?
On Wed, 20 Apr 2005 15:26:55 +0200, Jean-Francois Smigielski wrote:
C'est ici qu'intervient le "je fais ce qu'on me dit". Je clame depuis le début que l'ordre n'a pas bcp d'importance. Mais on me rétorque que je dois simuler de manière transparente une communication sur un BUS.
C'est du pontage ethernet, il faut donc transporter l'encapsulation ethernet.
GRE fonctionne au dessus d'un protocole de niveau 3, et doit donc être de niveau 4, non?
Non. La couche d'un protocole est définie par les services qu'il fournit à la couche supérieure, pas par la couche inférieure sur laquelle il s'appuie + 1. Autrement, on ne s'en sortirait pas. Ainsi PPP est toujours un protocole de niveau 2 même lorsqu'il est transporté dans L2TP sur UDP sur IP ou dans PPPoE sur ethernet. GRE est un protocole de niveau 2 puisqu'il offre un service de niveau 2 (liaison).
les seules encapsulations définies sont IPv4 dans GRE dans IPv4.
Quid de PPP dans GRE utilisé par le protocole PPTP ?
