On Wed, Jul 3, 2013 at 2:10 AM, James Cameron <qu...@laptop.org> wrote: > On Wed, Jul 03, 2013 at 02:06:04PM +0530, Anish Mangal wrote: >> >> >> On Wed, Jul 3, 2013 at 1:54 PM, James Cameron <qu...@laptop.org> wrote: >> >> On Wed, Jul 03, 2013 at 12:45:35PM +0530, Anish Mangal wrote: >> > James wrote: >> > > Would the person accessing their XSCE remotely then establish >> > > another tunnel to your OpenVPN server, or would your server do >> > > inbound connection forwarding? >> > >> > Hmm. I'm not so clear on that. I can give the example of a setup in >> > Bhagmalpur (a pilot we recently did). >> > >> > 1. There is an openVPN server hosted by Sameer. >> > 2. The XSCE when connected to the internet dials into this open vpn >> > server. >> >> Thanks, I understand the first two steps, and they sound good. >> >> > 3. I can login to the XSCE through the openVPN connection through >> > ssh and administer remotely. >> >> How is this last step achieved? There's much flexibility, so I'm >> curious. I imagine one of three methods: >> >> a. does the user first SSH into an account on the OpenVPN server and >> then SSH again to the XSCE, or; >> >> b. does the user SSH to a particular port on the OpenVPN server that >> is automatically forwarded to the XSCE, or; >> >> c. does the XSCE have a routable IP address, courtesy of the OpenVPN >> server, to which SSH is directed? >> >> >> >> I'm not sure... let me explain (perhaps Sameer or Santi can chime in)... >> >> I have a set of openVPN keys on may laptop through which I connect to the >> openVPN server automatically (and a network called tun0 is created) >> >> I know the IP address of the XSCE in Bpur >> >> So, from my laptop, I just do ssh root@<ip address of XSCE on the openVPN >> network> >> >> Does it make things any clearer? > > Yes, this would be a case "d", where both the client (your laptop) and > the server (the XSCE) have an unroutable address on a network that is > unreachable except through OpenVPN.
True. Both "clients" get a private IP within the same subnet. > > By unroutable I mean one that cannot be reached from the public > network. > True. In many cases, ISPs use private dynamic IPs, so getting to the server becomes difficult. > This is a good choice, because: > > - it allows the server hosting the OpenVPN to avoid dealing with > traffic unrelated to the task of remote access, > > - it allows the administrator of the OpenVPN server to set up packet > filtering rules to permit specific individuals to access specific > XSCEs, Yes, there are several ways to segment out the traffic using packet filtering on the server itself. The OpenVPN server acts like a hub initially, but because of the layer 3 packet filtering, it can then effective behave like a vLAN switch (although switching is a L2 tech). > > - it prevents access to either party from the public network. > Correct. > Now that you have remote XSCE settled, have you considered remote XO > access for hardware diagnosis and maintenance? Write up of that > feature is here: > > http://wiki.laptop.org/go/Firmware/Remote > > A relay using socat could be run on the XSCE for this purpose, and so > a user of the OpenVPN service could reach an XO (or another XSCE) to > analyse or fix non-booting scenarios. > > I know you already have the capability to deploy puppet for XO remote > administration ... if the Linux kernel is running. > > -- > James Cameron > http://quozl.linux.org.au/ > > Sameer -- Sameer Verma, Ph.D. Professor, Information Systems San Francisco State University http://verma.sfsu.edu/ http://commons.sfsu.edu/ http://olpcsf.org/ http://olpcjamaica.org.jm/ _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel