[Précédent (date)] [Suivant (date)] [Précédent (sujet)] [Suivant (sujet)] [Index par date] [Index par sujet]

Re: besoin d'une traduction

Va sur
http://clx.anet.fr/spip/article.php3?id_article=131
Ça devrait t'aider.

 --- marco <[email protected]> a écrit : >
Salut tout le monde.
> J'ai trouvé une doc pour "vnc via ssh" en anglais
> mais je n'y comprend
> pas grand chose.
> Si quelqu'un est bon en traduction et qu'il a le
> temps ce serait une
> bonne contribution pour les francophones non
> bilingues...
> 
> À moins qu'on me poste des docs en fr...
> 
> merci
> 
> 
> 
> -- 
> marco
> --
> Clé PGP publique : https://iftbqp.mine.nu/marco.asc
> 
> 
> I wrote:
> [ ... ssh tunnels, port forwarding, vnc ... ]
> 
> On Thu, Oct 07, 1999 at 07:19:36PM +1000, Darryl
> Harvey wrote:
> | And in English that means ???
> | Any clearer explanation on how to achieve this ?
> 
> Hmm, the penalties of trying to be succinct...
> 
> Ok, here's the long description:
> 
> I assume you know about VNC, but for the sake of
> clarity, here's how
> VNC works (since we need the networking details for
> the tunneling).
> Trust me - we _will_ get to the firewall and ssh.
> 
> VNC consists of two programs - a server and a
> viewer. This separation
> lets you have a session of some kind running on the
> server, and to
> start up and shutdown the viewer whenever and
> wherever you like.
> So you can view at work, set up something long
> running and GUIfied,
> then go home and work from there too.
> 
> VNC does this by having the server speak two
> protocols: the VNC
> protocol, which it speaks between the vncviewer and
> the vncserver (so
> that you can view any VNC server's session) and the
> native windowing
> protocol of whatever system the server's running the
> session on (for
> UNIX, this is X11).
> 
> So, on UNIX the vncserver acts as a X server, just
> like XFree86 and
> suchlike, but it doesn't talk to a video card. So,
> you fire up
> vncserver like so:
> 
>         vncserver 5     # <== pick some number - 0
> will be in use by
>                         # your "real" X display, so
> something else
> 
> This results in the server (Xvnc) firing up and
> listening on two
> ports:  6005 (for normal X clients like xterm, using
> the DISPLAY name
> "host:5", where "host" is the machine your running
> on), and 5905 (for
> vncviewers to connect to to see what's going on).
> So, for the VNC
> session numbered "n" it lists on port 6000+n as the
> X server :n and on
> port 5900+n as the VNC server ":n".
> 
> Digging through my old mail I find a diagram I drew
> for a friend, which
> I
> will adapt here. Here's a normal X session, such as
> you normally run:
> 
>              monitor
>                 |
>     You  <-> X server <---------X11 protocol-->
> client (eg xterm)
>                 |                                   
>   |
>              desktop                             
> client machine
>              machine                               
> (host B)
>              (host A)
> 
> Of course, hosts A and B needn't be separate
> machines. The client
> (xterm) is connected to port 6000 on host A, and
> speaks the X11
> graphics protocol to draw text and whatnot. The X
> server speaks to
> the video card of host A.
> 
> Here's a similar setup, using VNC as an
> intermediary:
> 
>              monitor
>                 |
>     You  <-> X server <---------X11 protocol-->
> vncviewer (a normal
>              monitor                             X
> client from host C's
>                 |                               
> point of view)
>               desktop                               
>  |
>               machine                               
>  |
>               (host C)                              
>  |
>                                                     
>  |
>                 +---------------VNC
> protocol----------+
>                 |
>                 V
>              X server <---------X11 protocol-->
> client (eg xterm)
>         (Xvnc in this case)                         
>   |
>                 |                                   
>   |
>              desktop                             
> client machine
>              machine                               
> (host B)
>              (host A)
> 
> Here we have you seated in front of host C, with the
> viewer open before
> you,
> showing the desktop on host A. Using the earlier
> example (VNC display
> #5)
> the vncviewer is:
>         - connected to port 6000 on host C, to
> display the desktop
>           on your local X display
>         - connected to port 5905 (== 5900+5, because
> "n" is 5) on host
> A,
>           to get the desktop contents from the
> vncserver
> The X clients on the desktop are:
>         - connected to port 6005 (== 6000+5) on host
> A, to write to the
> X
>           session called "hostA:5"
> 
> The Xvnc on host A is not controlling a video card.
> Instead, it depicts
> the X session it's supporting to any vncviewer which
> connects. (There's
> a login challenge when you connect to a VNC viewer,
> so don't imagine
> this leaves you wide open to Joe Cracker). Your
> vncviewer transcribes
> that to the X server on host C, and _that_ X server
> scribbles on your
> monitor.
> 
> So...
> 
> The original problem was that host C and host A were
> on different sides
> of a firewall. To the outer world (yea, even to the
> inner world) a
> firewall
> looks much like an ordinary router - a transparent
> box for passing
> packets
> back and forth between two networks, save the the
> firewall only passes
> some
> packets, not all. And thus the crackers are kept
> out.
> 
> The proposal was to open a hole in the firewall to
> pass VNC - in short,
> to
> instruct the firewall to pass packets to and from
> port 5905 (or
> whichever) on
> host A, and the outside world. While this would
> work, it's a bad idea
> for
> 
=== message truncated ===

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca