Je veux faire du VNC d'un PC d'un réseau à un autre PC d'un autre réseau
chaque réseau est connecté à internet par un routeur.
Apparement le routeur bloque l'accès à distance. Qu'est ce qu'il faut
configurer sur le routeur pour pouvoir accéder à un PC du réseau (Ports ?
Autres ?) par une liaison distante internet.
Ah ok ! Je ne connaissais pas VPN, et j'avais cru que la réponse de Alni était due à une lecture un peu trop rapide du mot VNC (ça ressemble quand meme un peu)
Tout à fait, je me suis fourvoyé, il n'était pourtant pas si tard.... Je ne sais pas pourquoi j'ai vu VPN au lieu de VNC.....
Déformation professionnelle ?... ;-)
"Alni" <nospam@nowhere.com> a écrit sur fr.comp.reseaux.ip :
Ah ok ! Je ne connaissais pas VPN, et j'avais cru que la réponse de
Alni était due à une lecture un peu trop rapide du mot VNC (ça
ressemble quand meme un peu)
Tout à fait, je me suis fourvoyé, il n'était pourtant pas si tard....
Je ne sais pas pourquoi j'ai vu VPN au lieu de VNC.....
Ah ok ! Je ne connaissais pas VPN, et j'avais cru que la réponse de Alni était due à une lecture un peu trop rapide du mot VNC (ça ressemble quand meme un peu)
Tout à fait, je me suis fourvoyé, il n'était pourtant pas si tard.... Je ne sais pas pourquoi j'ai vu VPN au lieu de VNC.....
Déformation professionnelle ?... ;-)
Etienne de Tocqueville
"Doroncel Leo Ph D," a écrit sur fr.comp.reseaux.ip :
Si VNC gère le port 5800.
Ah oui, effectivement, le 5800 est utilisé par VNC. Il y met derrière un mini serveur http qui transmet au client le viewer java, et qui permet donc de visualiser un écran VNC sans disposer du viewer standard.
Cela dit, meme si on utilise ce viewer java, il faut quand meme que le 5900 soit ouvert. Seul lui est utilisé par le viewer et c'est donc le seul que l'on peut avoir intéret à faire passer par un firewall.
Mais on parle généralement du port 5900 qui est aussi utilisé.
On parle « généralement » du 5900 parce que c'est celui qui est utile ;-)
"Doroncel Leo Ph D," <l.durancel@ifrance.com> a écrit sur fr.comp.reseaux.ip :
Si VNC gère le port 5800.
Ah oui, effectivement, le 5800 est utilisé par VNC. Il y met derrière un
mini serveur http qui transmet au client le viewer java, et qui permet
donc de visualiser un écran VNC sans disposer du viewer standard.
Cela dit, meme si on utilise ce viewer java, il faut quand meme que le
5900 soit ouvert. Seul lui est utilisé par le viewer et c'est donc le
seul que l'on peut avoir intéret à faire passer par un firewall.
Mais on parle généralement du port 5900 qui est aussi utilisé.
On parle « généralement » du 5900 parce que c'est celui qui est utile ;-)
"Doroncel Leo Ph D," a écrit sur fr.comp.reseaux.ip :
Si VNC gère le port 5800.
Ah oui, effectivement, le 5800 est utilisé par VNC. Il y met derrière un mini serveur http qui transmet au client le viewer java, et qui permet donc de visualiser un écran VNC sans disposer du viewer standard.
Cela dit, meme si on utilise ce viewer java, il faut quand meme que le 5900 soit ouvert. Seul lui est utilisé par le viewer et c'est donc le seul que l'on peut avoir intéret à faire passer par un firewall.
Mais on parle généralement du port 5900 qui est aussi utilisé.
On parle « généralement » du 5900 parce que c'est celui qui est utile ;-)
Etienne de Tocqueville
Eric Masson a écrit sur fr.comp.reseaux.ip :
Etienne> Le port 5800 n'est pas utilisé par le viewer de VNC...
Possible, je ne laisse jamais ce genre de protocole traverser un firewall, donc je ne me suis jamais vraiment penché sur le problème.
Moi non plus, mais c'est utile à savoir si l'on souhaite faire passer ce protocole dans du ssh
Eric Masson <emss@free.fr> a écrit sur fr.comp.reseaux.ip :
Etienne> Le port 5800 n'est pas utilisé par le viewer de VNC...
Possible, je ne laisse jamais ce genre de protocole traverser un
firewall, donc je ne me suis jamais vraiment penché sur le problème.
Moi non plus, mais c'est utile à savoir si l'on souhaite faire passer ce
protocole dans du ssh
Etienne> Le port 5800 n'est pas utilisé par le viewer de VNC...
Possible, je ne laisse jamais ce genre de protocole traverser un firewall, donc je ne me suis jamais vraiment penché sur le problème.
Moi non plus, mais c'est utile à savoir si l'on souhaite faire passer ce protocole dans du ssh
Eric Masson
"Etienne" == Etienne de Tocqueville <et+ writes:
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Eric Masson
-- Je précise que je défends aucunement le contributeur que vous insultez, car vous faites un amalgame entre ses opinions et convictions et le fait qu'il dise donc constamment des conneries. -+- JH in <http://www.le-gnu.net> : Bien étaler sa mauvaise foi -+-
"Etienne" == Etienne de Tocqueville <et+news@steph.teaser.fr> writes:
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire
Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Eric Masson
--
Je précise que je défends aucunement le contributeur que vous
insultez, car vous faites un amalgame entre ses opinions et
convictions et le fait qu'il dise donc constamment des conneries.
-+- JH in <http://www.le-gnu.net> : Bien étaler sa mauvaise foi -+-
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Eric Masson
-- Je précise que je défends aucunement le contributeur que vous insultez, car vous faites un amalgame entre ses opinions et convictions et le fait qu'il dise donc constamment des conneries. -+- JH in <http://www.le-gnu.net> : Bien étaler sa mauvaise foi -+-
Etienne de Tocqueville
Eric Masson a écrit sur fr.comp.reseaux.ip :
"Etienne" == Etienne de Tocqueville <et+ writes:
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements à mon Google favori. De ce que j'en ai compris, c'est pour faire du tunneling chiffré, donc comme ssh. Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
Eric Masson <emss@free.fr> a écrit sur fr.comp.reseaux.ip :
"Etienne" == Etienne de Tocqueville <et+news@steph.teaser.fr> writes:
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire
Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements
à mon Google favori. De ce que j'en ai compris, c'est pour faire du
tunneling chiffré, donc comme ssh. Alors en quoi IPsec roule plus grave
que ssh ?.. ;-)
Etienne> Moi non plus, mais c'est utile à savoir si l'on souhaite faire Etienne> passer ce protocole dans du ssh
ipsec roulaize grave ;)
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements à mon Google favori. De ce que j'en ai compris, c'est pour faire du tunneling chiffré, donc comme ssh. Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
Annie D.
Etienne de Tocqueville wrote:
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements à mon Google favori. De ce que j'en ai compris, c'est pour faire du tunneling chiffré,
Oui, du vrai tunnelling complet.
donc comme ssh. Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
SSH à la base, comme son nom l'indique, c'est avant tout pour faire du shell à distance, une sorte de telnet sécurisé. Il est agrémenté de quelques gadgets comme le transfert de fichiers et la redirection de ports TCP locaux, mais c'est assez limité de ce côté. Alors que IPSec, c'est du vrai réseau IP.
Etienne de Tocqueville wrote:
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements
à mon Google favori. De ce que j'en ai compris, c'est pour faire du
tunneling chiffré,
Oui, du vrai tunnelling complet.
donc comme ssh. Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
SSH à la base, comme son nom l'indique, c'est avant tout pour faire du
shell à distance, une sorte de telnet sécurisé. Il est agrémenté de
quelques gadgets comme le transfert de fichiers et la redirection de
ports TCP locaux, mais c'est assez limité de ce côté. Alors que IPSec,
c'est du vrai réseau IP.
Je ne connais pas IPsec, alors je suis allé réclamer des renseignements à mon Google favori. De ce que j'en ai compris, c'est pour faire du tunneling chiffré,
Oui, du vrai tunnelling complet.
donc comme ssh. Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
SSH à la base, comme son nom l'indique, c'est avant tout pour faire du shell à distance, une sorte de telnet sécurisé. Il est agrémenté de quelques gadgets comme le transfert de fichiers et la redirection de ports TCP locaux, mais c'est assez limité de ce côté. Alors que IPSec, c'est du vrai réseau IP.
Eric Masson
"Etienne" == Etienne de Tocqueville <et+ writes:
Etienne> De ce que j'en ai compris, c'est pour faire du tunneling Etienne> chiffré, donc comme ssh.
Entre autres...
Etienne> Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
Petite présentation très/trop rapide et références si tu veux en savoir plus.
Il est implémenté au niveau ip, tout protocole de niveau supérieur peut donc en profiter sans nécessiter de modification.
Il est optionnel en ipv4 et obligatoire pour une implémentation ipv6
Il définit deux mécanismes principaux pour la sécurité d'un lien, qui sont utilisables conjointement ou séparément.: - AH qui permet de s'assurer qu'un paquet provient bien d'un hôte dûment authentifié. - ESP qui permet d'appliquer des transformations cryptographiques sur la charge utile du paquet.
Deux modes de fonctionnement sont définis : - transport qui assure une protection de bout en bout de la connexion (chaque extrémité du lien a une pile ip paramétrée pour utiliser ipsec) - tunnel qui assure une protection entre passerelles de sécurité (c'est la topologie dont parle Annie dans sa réponse)
Il est possible de spécifier quel type de traffic doit subir les transformations cryptographiques.
La négociation des clés nécessaires aux mécanismes cryptographiques peut être manuelle ou alors faire appel à un protocole spécialisé dans ce rôle (ISAKMP principalement)
IPsec (l'ensemble de protocoles) évolue régulièrement, une des implémentations de référence IPv6/IPsec est la souche KAME, intégrée dans les BSD et iirc dans la série 2.6 du noyau Linux.
Cette souche dispose de pas de doc, disponible à partir du lien suivant http://www.kame.net
Pour des infos plus orientées mise en oeuvre, tu peux regarder les liens suivants : http://www.netbsd.org/Documentation/network/ipsec/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
La défunte section 13 de la FAQ d'OpenBSD était assez sympa pour appréhender l'implémentation d'Open (l'isakmpd d'Open n'est pas celui de la souche Kame)
Vala, vala
Eric Masson
-- On chie sur la nettiquéquette ! La liberté d'expression tu connais ? Moi ça ne me dérange pas du tout de voir des pubs sur les news, ce le libre commerce. Clovis -+-in : <http://www.le-gnu.net> - Bien revendiquer sa connerie -+-
"Etienne" == Etienne de Tocqueville <et+news@steph.teaser.fr> writes:
Etienne> De ce que j'en ai compris, c'est pour faire du tunneling
Etienne> chiffré, donc comme ssh.
Entre autres...
Etienne> Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
Petite présentation très/trop rapide et références si tu veux en savoir
plus.
Il est implémenté au niveau ip, tout protocole de niveau supérieur peut
donc en profiter sans nécessiter de modification.
Il est optionnel en ipv4 et obligatoire pour une implémentation ipv6
Il définit deux mécanismes principaux pour la sécurité d'un lien, qui
sont utilisables conjointement ou séparément.:
- AH qui permet de s'assurer qu'un paquet provient bien d'un hôte dûment
authentifié.
- ESP qui permet d'appliquer des transformations cryptographiques sur la
charge utile du paquet.
Deux modes de fonctionnement sont définis :
- transport qui assure une protection de bout en bout de la connexion
(chaque extrémité du lien a une pile ip paramétrée pour utiliser
ipsec)
- tunnel qui assure une protection entre passerelles de sécurité (c'est
la topologie dont parle Annie dans sa réponse)
Il est possible de spécifier quel type de traffic doit subir les
transformations cryptographiques.
La négociation des clés nécessaires aux mécanismes cryptographiques peut
être manuelle ou alors faire appel à un protocole spécialisé dans ce
rôle (ISAKMP principalement)
IPsec (l'ensemble de protocoles) évolue régulièrement, une des
implémentations de référence IPv6/IPsec est la souche KAME, intégrée
dans les BSD et iirc dans la série 2.6 du noyau Linux.
Cette souche dispose de pas de doc, disponible à partir du lien suivant
http://www.kame.net
Pour des infos plus orientées mise en oeuvre, tu peux regarder les liens
suivants :
http://www.netbsd.org/Documentation/network/ipsec/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
La défunte section 13 de la FAQ d'OpenBSD était assez sympa pour
appréhender l'implémentation d'Open (l'isakmpd d'Open n'est pas celui de
la souche Kame)
Vala, vala
Eric Masson
--
On chie sur la nettiquéquette ! La liberté d'expression tu connais ? Moi
ça ne me dérange pas du tout de voir des pubs sur les news, ce le libre
commerce. Clovis
-+-in : <http://www.le-gnu.net> - Bien revendiquer sa connerie -+-
Etienne> De ce que j'en ai compris, c'est pour faire du tunneling Etienne> chiffré, donc comme ssh.
Entre autres...
Etienne> Alors en quoi IPsec roule plus grave que ssh ?.. ;-)
Petite présentation très/trop rapide et références si tu veux en savoir plus.
Il est implémenté au niveau ip, tout protocole de niveau supérieur peut donc en profiter sans nécessiter de modification.
Il est optionnel en ipv4 et obligatoire pour une implémentation ipv6
Il définit deux mécanismes principaux pour la sécurité d'un lien, qui sont utilisables conjointement ou séparément.: - AH qui permet de s'assurer qu'un paquet provient bien d'un hôte dûment authentifié. - ESP qui permet d'appliquer des transformations cryptographiques sur la charge utile du paquet.
Deux modes de fonctionnement sont définis : - transport qui assure une protection de bout en bout de la connexion (chaque extrémité du lien a une pile ip paramétrée pour utiliser ipsec) - tunnel qui assure une protection entre passerelles de sécurité (c'est la topologie dont parle Annie dans sa réponse)
Il est possible de spécifier quel type de traffic doit subir les transformations cryptographiques.
La négociation des clés nécessaires aux mécanismes cryptographiques peut être manuelle ou alors faire appel à un protocole spécialisé dans ce rôle (ISAKMP principalement)
IPsec (l'ensemble de protocoles) évolue régulièrement, une des implémentations de référence IPv6/IPsec est la souche KAME, intégrée dans les BSD et iirc dans la série 2.6 du noyau Linux.
Cette souche dispose de pas de doc, disponible à partir du lien suivant http://www.kame.net
Pour des infos plus orientées mise en oeuvre, tu peux regarder les liens suivants : http://www.netbsd.org/Documentation/network/ipsec/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
La défunte section 13 de la FAQ d'OpenBSD était assez sympa pour appréhender l'implémentation d'Open (l'isakmpd d'Open n'est pas celui de la souche Kame)
Vala, vala
Eric Masson
-- On chie sur la nettiquéquette ! La liberté d'expression tu connais ? Moi ça ne me dérange pas du tout de voir des pubs sur les news, ce le libre commerce. Clovis -+-in : <http://www.le-gnu.net> - Bien revendiquer sa connerie -+-
Etienne de Tocqueville
Eric Masson a écrit sur fr.comp.reseaux.ip :
Petite présentation très/trop rapide et références si tu veux en savoir plus.
Merci beaucoup pour cette rapide mais instructive presentation de la chose :-) Mais premières recherches m'avait un peu noyé ;-)
Eric Masson <emss@free.fr> a écrit sur fr.comp.reseaux.ip :
Petite présentation très/trop rapide et références si tu veux en savoir
plus.
Merci beaucoup pour cette rapide mais instructive presentation de la
chose :-) Mais premières recherches m'avait un peu noyé ;-)
