Port forwarding inside UMview

From Virtualsquare
Revision as of 19:05, 27 December 2012 by Renzo (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The purpose of this tutorial is to put various features of UMview and Virtual Distributed Ethernet networks together and see what can be done and what are the perspectives of such a paravirtualization environment.

Since UMview provides virtual tcp/ip stacks to its processes, each per-process tcp/ip stack can be connected to a vde network. If we add to this scenario the slirpvde tool, although it was designed to provide internet connectivity to virtual machines, it can be used to connect single processes to the host network. It is also possible to forward ports of the host machine to processes with the result that several ports can be mapped onto several processes.

Overview


 

Portfw slirpvde.png
  • local network:
192.168.0.0/24
  • slirpvde network:
192.168.77.0/24
  • host address:
192.168.0.100
  • slirpvde address:
192.168.77.2
  • umview processes addresses:
192.168.77.{100,101,102}

 


The figure above shows in a graphical fashion what we are going to set up in this tutorial. On the left there are several netcat clients connecting to hosting machine tcp ports; slirpvde intercepts connections to specitied ports and redirects them to specified umview processes.

Setting up a set of networked processes

First of all we need a vde_switch to connect UMview processes to.

$ vde_switch -d -s /tmp/vde -M /tmp/mgmt

In this example we will use a small set of UMview processes, say three. We are going to start three interactive bash shells each with its own new view of the system. Since we want to interact simultaneously with all three processes each one have to be started from different virtual consoles or terminals (i.e. xterm).

$ umview bash

Once umview has been started the Light Weight IPv6 service module has to be loaded in all umview instances. Note that for each umview instance have been specified the creation of a virtual network interface connected to the previously created switch.

$ um_add_service lwipv6.so,vd0=/tmp/vde

The network interfaces just created have to be brought up using iproute2 commands. Configuration of such network interfaces is not allowed with commands like ifconfig or route since they rely on /proc pseudo-filesystem. iproute2 tools have to be used instead because they have direct access to kernel networking hooks via syscalls that will be intercepted by umview.

$ ip link set vd0 up

To each umview instance is assigned a different ip address of the same /24 subnet. It is also possible to use dynamic host configuration protocol DHCP provided by slirpvde but for the purpose of this tutorial ip addresses assigned to each process have to be known a priori to set up port forwarding correctly.

$ ip addr add 192.168.77.100/24 dev vd0
$ ip addr add 192.168.77.101/24 dev vd0
$ ip addr add 192.168.77.102/24 dev vd0

Now each umview process can reach each other via the vde_switch. Looking at vde_switch management interface it is possible to see ports status.

$ echo port/print | unixterm -i -s /tmp/mgmt 
mgmt: Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0006 module unix prog   : LWIPv6 user=render PID=642 if=vd0
mgmt: Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0008 module unix prog   : LWIPv6 user=render PID=653 if=vd0
mgmt: Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0010 module unix prog   : LWIPv6 user=render PID=664 if=vd0

Connecting virtual network to host machine

In each umview instance have to be specified the default route as the address assigned by default to slirpvde. In this way all umview processes is connected to the host machine network with network address translation operated by slirpvde.

$ ip route add default via 192.168.77.2

Before starting slirpvde we have to specify which ports of the hosting machine are going to be mapped onto umview processes. To increase readability port forwarding directives can be written to a text file and than passed to slirpvde via command line substitution.

$ cat portforward.txt
-L30000:192.168.77.100:10000
-L30001:192.168.77.101:10000
-L30002:192.168.77.102:10000

Commands in text file will tell slirpvde to forward ports interval between 30000-30002 to port 10000 of each umview process identified by its own ip address in the virtual subnet. Now slirpvde can be started as a daemon and connected to the vde_switch. In the command line have been specified as parameters the subnet ip address, the path of vde_switch data socket and the list of port-forwarding rules.

$ slirpvde -d -s /tmp/vde -n 192.168.77.0 `cat portforward.txt`

Wit a look to vde_switch port status it is possible to see that a new port has been marked as active and it has been associated with slirpvde process.

$ echo port/print | unixterm -i -s /tmp/mgmt 
mgmt: Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0006 module unix prog   : LWIPv6 user=render PID=642 if=vd0
mgmt: Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0008 module unix prog   : LWIPv6 user=render PID=653 if=vd0
mgmt: Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0010 module unix prog   : LWIPv6 user=render PID=664 if=vd0
mgmt: Port 0004 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
mgmt:   -- endpoint ID 0012 module unix prog   : slirpvde: user=render PID=691  SOCK=/tmp/vde.00691-00000

It's time to check if it works

To see if port forwarding works we will use a simple networking tool called netcat. Netcat can be used both as client and as server acting as a kind of pipe over tcp/ip between two hosts. We start the test by launching a listening netcat on each umview process, waiting for connections to port 10000.

$ netcat -vv -l -n -p 10000

A brief explanation of netcat option used:

  • -vv to enable verbosity and to see where the connection comes from;
  • -l means to listen for incoming connections;
  • -n turns off reverse domain name resolution;
  • -p specifies the port it is going to listen to.

Then from the hosting machine we will try to connect to ports mapped to umview processes. In our case the hosting machine ip address is 192.168.0.100.

Port 30000 of hosting machine is mapped to 192.168.77.100 umview process.

$ netcat 192.168.0.100 30000
foo
bar
baz
$

$ netcat -vv -l -n -p 10000
listening on [any] 10000 ...
connect to [192.168.77.100] from (UNKNOWN) [192.168.0.100] 3084
foo
bar
baz
 sent 0, rcvd 12

Port 30001 of hosting machine is mapped to 192.168.77.101 umview process.

$ netcat 192.168.0.100 30001
foo
bar
baz
$

$ netcat -vv -l -n -p 10000
listening on [any] 10000 ...
connect to [192.168.77.101] from (UNKNOWN) [192.168.0.100] 3845
foo
bar
baz
 sent 0, rcvd 12

Port 30002 of hosting machine is mapped to 192.168.77.102 umview process.

$ netcat 192.168.0.100 30002
foo
bar
buzz
$

$ netcat -vv -l -n -p 10000
listening on [any] 10000 ...
connect to [192.168.77.102] from (UNKNOWN) [192.168.0.100] 3700
foo
bar
buzz
 sent 0, rcvd 13
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox