Je m'interrogeais sur le fait de savoir s'il était possible de réaliser un programme
de NAT en Java.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer
(je récupère toutes les trames réseau et je modifie les adresses IP originales et
destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java
qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me
trompe je?
Sébastien
--
Message monitoré par axinews : http://www.axinews.com/
Il y a apparement 2 versions complètement différentes de Jpcap (meme si elle ont le meme nom...) dont une permettant d'envoyer des packets via les rowsockets
Il y a apparement 2 versions complètement différentes de Jpcap (meme si elle
ont le meme nom...) dont une permettant d'envoyer des packets via les
rowsockets
Il y a apparement 2 versions complètement différentes de Jpcap (meme si elle ont le meme nom...) dont une permettant d'envoyer des packets via les rowsockets
TestMan
Bonjour,
Je m'interrogeais sur le fait de savoir s'il était possible de réaliser un programme de NAT en Java.
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer (je récupère toutes les trames réseau et je modifie les adresses IP originales et destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui marche trés bien: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Construire un NAT en Java est vraiment une bonne idée ;-)
A+ TestMan
Bonjour,
Je m'interrogeais sur le fait de savoir s'il était possible de réaliser un programme
de NAT en Java.
C'est relativement simple ;-)
Relativement, car pour NATter les protocoles style TCP et UDP cela est
simple ... mais NATer les services style particulier style FTP et H323,
c'est plus compliqué.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer
(je récupère toutes les trames réseau et je modifie les adresses IP originales et
destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java
qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me
trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui
marche trés bien:
http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Construire un NAT en Java est vraiment une bonne idée ;-)
Je m'interrogeais sur le fait de savoir s'il était possible de réaliser un programme de NAT en Java.
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer (je récupère toutes les trames réseau et je modifie les adresses IP originales et destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui marche trés bien: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Construire un NAT en Java est vraiment une bonne idée ;-)
A+ TestMan
Seb X
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs interfaces (en java du moins) et je ne sais pas encore si il sera possible de remédier à cela. Quelqu'un s'est déjà penché sur la question en fait : http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Je pense que la solution serait de porter la librairie libdnet en java via JNI
C'est relativement simple ;-)
Relativement, car pour NATter les protocoles style TCP et UDP cela est
simple ... mais NATer les services style particulier style FTP et H323,
c'est plus compliqué.
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs
interfaces (en java du moins) et je ne sais pas encore si il sera possible
de remédier à cela.
Quelqu'un s'est déjà penché sur la question en fait :
http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Je pense que la solution serait de porter la librairie libdnet en java via
JNI
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs interfaces (en java du moins) et je ne sais pas encore si il sera possible de remédier à cela. Quelqu'un s'est déjà penché sur la question en fait : http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Je pense que la solution serait de porter la librairie libdnet en java via JNI
TestMan
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs interfaces (en java du moins) et je ne sais pas encore si il sera possible de remédier à cela.
sûr ?! faudra que je teste ça à l'occaze, remarque, je l'utilise que pour une interface à la fois, pas etonnant que cela ne me pose pas de PB ;-)
Quelqu'un s'est déjà penché sur la question en fait : http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Trés interessant <:o)
Je pense que la solution serait de porter la librairie libdnet en java via JNI
jpcap, est tout de même un bon début ... mais si t'es motivé ;-)
A+ TestMan
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs
interfaces (en java du moins) et je ne sais pas encore si il sera possible
de remédier à cela.
sûr ?! faudra que je teste ça à l'occaze, remarque, je l'utilise que
pour une interface à la fois, pas etonnant que cela ne me pose pas de PB
;-)
Quelqu'un s'est déjà penché sur la question en fait :
http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Trés interessant <:o)
Je pense que la solution serait de porter la librairie libdnet en java via
JNI
jpcap, est tout de même un bon début ... mais si t'es motivé ;-)
Nan pas si simple car la jpcap ne permet pas d'écouter sur plusieurs interfaces (en java du moins) et je ne sais pas encore si il sera possible de remédier à cela.
sûr ?! faudra que je teste ça à l'occaze, remarque, je l'utilise que pour une interface à la fois, pas etonnant que cela ne me pose pas de PB ;-)
Quelqu'un s'est déjà penché sur la question en fait : http://arm.gobelins.fr/users/gpaul/ITIN_MEMOIRE/Firewall.pdf
Trés interessant <:o)
Je pense que la solution serait de porter la librairie libdnet en java via JNI
jpcap, est tout de même un bon début ... mais si t'es motivé ;-)
A+ TestMan
Seb X
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer
(je récupère toutes les trames réseau et je modifie les adresses IP originales et
destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java
qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me
trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui marche trés bien: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Oui, sauf que le lecture sur une seule interface empêche pour le moment d'aller plus loin.... Je pense que le problème vient de Jpcap et non de libcap. Je vais essayer la version de sourceforge qui permet peut être de lire sur plus d'une interface réseau à la fois
Construire un NAT en Java est vraiment une bonne idée ;-)
A+ TestMan
C'est relativement simple ;-)
Relativement, car pour NATter les protocoles style TCP et UDP cela est
simple ... mais NATer les services style particulier style FTP et H323,
c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile?
La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous
les protocoles de plus haut niveau que la couche réseau.
La translation d'adresse fonctionne apparemment un peu à la manière d'un
sniffer
(je récupère toutes les trames réseau et je modifie les adresses IP
originales et
destinataires pour créer la NAT). Ce travail me semble difficile à faire
en Java
qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les
réseaux. Me
trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui
marche trés bien:
http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Oui, sauf que le lecture sur une seule interface empêche pour le moment
d'aller plus loin.... Je pense que le problème vient de Jpcap et non de
libcap. Je vais essayer la version de sourceforge qui permet peut être de
lire sur plus d'une interface réseau à la fois
Construire un NAT en Java est vraiment une bonne idée ;-)
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
La translation d'adresse fonctionne apparemment un peu à la manière d'un sniffer
(je récupère toutes les trames réseau et je modifie les adresses IP originales et
destinataires pour créer la NAT). Ce travail me semble difficile à faire en Java
qui apparemment ne prend pas en charge d'aussi "bas niveau" dans les réseaux. Me
trompe je?
Je te conseille le JPCap (la version japonaise pas celle de SF), qui marche trés bien: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
Oui, sauf que le lecture sur une seule interface empêche pour le moment d'aller plus loin.... Je pense que le problème vient de Jpcap et non de libcap. Je vais essayer la version de sourceforge qui permet peut être de lire sur plus d'une interface réseau à la fois
Construire un NAT en Java est vraiment une bonne idée ;-)
A+ TestMan
Seb X
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous
les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les protocoles qui passent l'adresse IP ou le port du client dans les données.
En ftp, quand le client fait un FTP port, il indique son adresse et un port où le serveur va pouvoir se connecter pour envoyer les données. Le routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa table sinon le serveur va avoir du mal à se connecter ...
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Pourquoi NATer les services FTP ou autre serait difficile?
La translation d'adresse a justement pour intérêt d'éviter d'encapsuler
tous
les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les
protocoles qui passent l'adresse IP ou le port du client dans les
données.
En ftp, quand le client fait un FTP port, il indique son adresse et un
port où le serveur va pouvoir se connecter pour envoyer les données. Le
routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa
table sinon le serveur va avoir du mal à se connecter ...
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne
pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne
bloquais aucune connexion que j'initiais et bloquais toute celle que je
n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai
moyennement envie d'éplucher toutes les RFC
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous
les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les protocoles qui passent l'adresse IP ou le port du client dans les données.
En ftp, quand le client fait un FTP port, il indique son adresse et un port où le serveur va pouvoir se connecter pour envoyer les données. Le routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa table sinon le serveur va avoir du mal à se connecter ...
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Cédric Chabanois
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les protocoles qui passent l'adresse IP ou le port du client dans les données.
En ftp, quand le client fait un FTP port, il indique son adresse et un port où le serveur va pouvoir se connecter pour envoyer les données. Le routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa table sinon le serveur va avoir du mal à se connecter ...
Cédric
Pourquoi NATer les services FTP ou autre serait difficile?
La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous
les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les
protocoles qui passent l'adresse IP ou le port du client dans les données.
En ftp, quand le client fait un FTP port, il indique son adresse et un
port où le serveur va pouvoir se connecter pour envoyer les données. Le
routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa
table sinon le serveur va avoir du mal à se connecter ...
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
Non, il a raison. Le ftp n'est pas évident à traiter comme tous les protocoles qui passent l'adresse IP ou le port du client dans les données.
En ftp, quand le client fait un FTP port, il indique son adresse et un port où le serveur va pouvoir se connecter pour envoyer les données. Le routeur NAT doit analyser les paquets ftp envoyés pour mettre à jour sa table sinon le serveur va avoir du mal à se connecter ...
Cédric
Cédric Chabanois
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ... Pour le H323 c'est le même genre de problème aussi
Cédric
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne
pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne
bloquais aucune connexion que j'initiais et bloquais toute celle que je
n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai
moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ...
Pour le H323 c'est le même genre de problème aussi
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ... Pour le H323 c'est le même genre de problème aussi
Cédric
Erwan David
"Seb X" écrivait :
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
Parceque en ftp ou H323 la payload TCP contient des informations du genre "connecte toi à l'IP truc, port machin". La NAT doit donc ouvrir un tunnel de son côté pour cette IP interne et ce port et modifier la payload pour donner l'IP de la NAT et le port du tunnel.
C'est relativement simple ;-)
Relativement, car pour NATter les protocoles style TCP et UDP cela est
simple ... mais NATer les services style particulier style FTP et H323,
c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile?
La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous
les protocoles de plus haut niveau que la couche réseau.
Parceque en ftp ou H323 la payload TCP contient des informations du
genre "connecte toi à l'IP truc, port machin". La NAT doit donc ouvrir
un tunnel de son côté pour cette IP interne et ce port et modifier la
payload pour donner l'IP de la NAT et le port du tunnel.
C'est relativement simple ;-) Relativement, car pour NATter les protocoles style TCP et UDP cela est simple ... mais NATer les services style particulier style FTP et H323, c'est plus compliqué.
Pourquoi NATer les services FTP ou autre serait difficile? La translation d'adresse a justement pour intérêt d'éviter d'encapsuler tous les protocoles de plus haut niveau que la couche réseau.
Parceque en ftp ou H323 la payload TCP contient des informations du genre "connecte toi à l'IP truc, port machin". La NAT doit donc ouvrir un tunnel de son côté pour cette IP interne et ce port et modifier la payload pour donner l'IP de la NAT et le port du tunnel.
Erwan David
Cédric Chabanois écrivait :
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas) J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ... Pour le H323 c'est le même genre de problème aussi
C'ets même pire pour le H323 parcequ'il faut faire un décodage ASN.1 pour retrouver les ports et IP, tandis qu'en FTP c'est directement de l'ASCII.
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne
pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne
bloquais aucune connexion que j'initiais et bloquais toute celle que je
n'initialisais pas)
J'espère qu'il n'y a pas trop de protocoles utilisant ce principe
car j'ai
moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ...
Pour le H323 c'est le même genre de problème aussi
C'ets même pire pour le H323 parcequ'il faut faire un décodage ASN.1
pour retrouver les ports et IP, tandis qu'en FTP c'est directement de
l'ASCII.
Hummm, je soupçonnai ce genre de problème. J'avais remarqué que je ne pouvais utiliser le FTP lorsque mon firewall était allumé (malgré que je ne bloquais aucune connexion que j'initiais et bloquais toute celle que je n'initialisais pas) J'espère qu'il n'y a pas trop de protocoles utilisant ce principe car j'ai moyennement envie d'éplucher toutes les RFC
Les firewalls savent gérer ce genre de problèmes, surtout pour le ftp ... Pour le H323 c'est le même genre de problème aussi
C'ets même pire pour le H323 parcequ'il faut faire un décodage ASN.1 pour retrouver les ports et IP, tandis qu'en FTP c'est directement de l'ASCII.
