VPN: Test to set up & validate a Client connection to the Server

VPN: Test to set up & validate a Client connection to the Server

Details

  This changeset creates an autotest suite 'network_VPN'  and a single
  test which sets up and validates that a VPN connection can be
  created from the Client (DUT) to the Server (rspro).

  The steps of the test are described in '000VPNGenesis'.

  The steps to manage the WiFi connection are copied from another
  test.

Testing

  I'm using 'cell 1' in the chromelab.  The rspro router is running a
  firmware with openvpn compiled in.

  You must have the following 53d0a92e9b0b37daebc795cc1ea4684d1c0dffd8
  from chromeos/master to have the necessary configuration changes to
  the openwrt repository.  You must then build the 'rspro' variant and
  upgrade your router with the new firmware to be able to run this
  test.

  Executed the test with the following command in my chroot:

     ./bin/cros_run_wifi_tests.sh --cell 1 --lab chromelab VPN

  This ultimately produces:

    network_VPN                           PASS
    network_VPN/network_VPN.000VPNGenesis PASS
      client_ping_avg                     2.580
      client_ping_frequency               2412
      client_ping_loss                    0
      client_ping_max                     4.216
      client_ping_min                     2.167
      client_ping_phymode                 802.11g
      client_ping_recv                    10
      client_ping_security                802_1x
      client_ping_xmit                    10
      connect_acquire_s                   4.527
      connect_assoc_s                     0.311
      connect_config_s                    0.395
      connect_frequency                   2412
      connect_select_s                    0.010
    -------------------------------------------
    Total PASS: 2/2 (100%)

Change-Id: I69e2e9a5680a8ae2db7e27e61ed96592ad460a55

VPN connectivity through the DUT to the server works

Change-Id: Ifaeff9a39668805a19778c6be3e22d96fdf995e8

This change adds 'Diffie-Hellman 1024' to the set of available certificates.  This is part of the OpenVPN-on-rspro effort.

Change-Id: Ief3b7872ffd3f6ea554875864f681b22e5437554

BUG=12882
TEST=

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=9963dc1

[thutt1, 2011-03-03 22:56:46]

Anyone have time to take a look at my first attempt?

[Paul Stewart, 2011-03-03 23:18:42]

Pretty good for a first pass!  A few things to address.

http://codereview.chromium.org/6609034/diff/2001/server/site_linux_server.py
File server/site_linux_server.py (right):

http://codereview.chromium.org/6609034/diff/2001/server/site_linux_server.py#...
server/site_linux_server.py:28: def vpn_launch_server(self, params):
The function name says "vpn_xxx" but you're really doing only openvpn.

http://codereview.chromium.org/6609034/diff/2001/server/site_tests/network_VP...
File server/site_tests/network_VPN/000VPNGenesis (right):

http://codereview.chromium.org/6609034/diff/2001/server/site_tests/network_VP...
server/site_tests/network_VPN/000VPNGenesis:45: [ "connect",        {
"security":"802_1x",
It's fine to do this, but your life might be made easier if you didn't go the
full 9 yards with EAP-TLS certificates for your WiFi setup.  It would make the
file more readable.

http://codereview.chromium.org/6609034/diff/2001/server/site_wifitest.py
File server/site_wifitest.py (right):

http://codereview.chromium.org/6609034/diff/2001/server/site_wifitest.py#newc...
server/site_wifitest.py:1183: def vpn_launch_client(self, params):
I suggest you call these "openvpn_*" instead of "vpn_*" since they are specific
to openvpn, and it's likely we'll have other vpn types.  Either that or you
should make a "TODO" to make these functions generic as more VPN types come
along.

[Paul Stewart, 2011-03-04 17:00:18]

On 2011/03/03 23:18:42, Paul Stewart wrote:
> I suggest you call these "openvpn_*" instead of "vpn_*" since they are
specific
> to openvpn, and it's likely we'll have other vpn types.  Either that or you
> should make a "TODO" to make these functions generic as more VPN types come
> along.

We had an incomplete offline conversation about the underlying
motivation for my desire for this code to either be made generic
or for the name to be more specific to OpenVPN.  A concrete example
of my concern is that http://codereview.chromium.org/6513009/ is
quickly surfacing which will add l2tp vpn client functionality.  If
you look there, connect-vpn has been enhanced to use a separate
connect parameter, and I'm sure we'd like to be able to test this
much like what you're doing right now with OpenVPN.

If you can take a little time to glance at the argument changes, you can make a
determination as to whether you'd rather have a generic function that took as an
argument which sort of VPN connection should be crated, or whether you want to
make the function specific to openvpn, and rename the function to reflect this. 
The situation is similar for site_linux_server.py.

[thutt1, 2011-03-04 21:48:02]

Paul,

I think I've addressed all your concerns.

[thutt, 2011-03-08 16:02:51]

Rebuilding & reinstalling on the DUT solved the issues I was having with
slowness.  I think I've addressed everything, and the tests run cleanly:


------------------------------------------------------------------------------
/tmp/run_remote_tests.wLsv/network_VPN                                   PASS
/tmp/run_remote_tests.wLsv/network_VPN/network_VPN.000VPNGenesis         PASS
  client_ping_avg                                                        3.539
  client_ping_frequency                                                  2412
  client_ping_loss                                                       30
  client_ping_max                                                        7.342
  client_ping_min                                                        2.827
  client_ping_phymode                                                    802.11g
  client_ping_recv                                                       7
  client_ping_security                                                   none
  client_ping_xmit                                                       10
  connect_acquire_s                                                      5.447
  connect_assoc_s                                                        0.050
  connect_config_s                                                       0.439
  connect_frequency                                                      2412
  connect_select_s                                                       4.479
/tmp/run_remote_tests.wLsv/network_VPN/network_VPN.001VPNNoKindSpecified PASS
------------------------------------------------------------------------------
Total PASS: 3/3 (100%)

[Paul Stewart, 2011-03-08 16:56:54]

LGTM with two teensy nits (okay to push without, though the 'vpn-host-ip' change
could avoid problems in the future).

http://codereview.chromium.org/6609034/diff/13002/server/site_tests/network_V...
File server/site_tests/network_VPN/000VPNGenesis (right):

http://codereview.chromium.org/6609034/diff/13002/server/site_tests/network_V...
server/site_tests/network_VPN/000VPNGenesis:70: "vpn-host-ip":"192.168.2.254",
Would suggest you remove the 'vpn-host-ip' parameter here, since you have this
parameter nicely defaulted now.

http://codereview.chromium.org/6609034/diff/13002/server/site_wifitest.py
File server/site_wifitest.py (right):

http://codereview.chromium.org/6609034/diff/13002/server/site_wifitest.py#new...
server/site_wifitest.py:1225: cert_pathnames[cert] = pathname
The three lines above bake down to "cert_pathnames = params.get('files', {})"