From 093d8fd0cd20591ab462dbf0c653735829f83906 Mon Sep 17 00:00:00 2001 From: The Robur Team Date: Mon, 28 Oct 2024 17:31:22 +0000 Subject: [PATCH] Pushed by YOCaml 2 from 7f47c4032f5ab40e0876a5259b296c230cb898ad --- articles/miragevpn-testing.html | 67 +++++++++++++++++++++++++++++++++ feed.xml | 7 ++++ index.html | 13 +++++++ tags.html | 17 ++++++--- 4 files changed, 98 insertions(+), 6 deletions(-) create mode 100644 articles/miragevpn-testing.html diff --git a/articles/miragevpn-testing.html b/articles/miragevpn-testing.html new file mode 100644 index 0000000..db722d3 --- /dev/null +++ b/articles/miragevpn-testing.html @@ -0,0 +1,67 @@ + + + + + + + + Robur's blogTesting MirageVPN against OpenVPN™ + + + + + + + + +
+

blog.robur.coop

+
+ The Robur cooperative blog. +
+
+
Back to index + +
+

Testing MirageVPN against OpenVPN™

+

As our last milestone for the EU NGI Assure funded MirageVPN project (for now) we have been working on testing MirageVPN, our OpenVPN™-compatible VPN implementation against the upstream OpenVPN™. +During the development we have conducted many manual tests. +However, this scales poorly and it is easy to forget testing certain cases. +Therefore, we designed and implemented interoperability testing, driving the C implementation on the one side, and our OCaml implementation on the other side. The input for such a test is a configuration file that both implementations can use. +Thus we test establishment of the tunnel as well as the tunnel itself.

+

While conducting the tests, our instrumented binaries expose code coverage information. We use that to guide ourselves which other configurations are worth testing. Our goal is to achieve a high code coverage rate while using a small amount of different configurations. These interoperability tests are running fast enough, so they are executed on each commit by CI.

+

A nice property of this test setup is that it runs with an unmodified OpenVPN binary. +This means we can use an off-the-shelf OpenVPN binary from the package repository and does not entail further maintenance of an OpenVPN fork. +Testing against a future version of OpenVPN becomes trivial. +We do not just test a single part of our implementation but achieve an end-to-end test. +The same configuration files are used for both our implementation and the C implementation, and each configuration is used twice, once our implementation acts as the client, once as the server.

+

We added a flag to our client and our recently finished server applications, --test, which make them to exit once a tunnel is established and an ICMP echo request from the client has been replied to by the server. +Our client and server can be run without a tun device which otherwise would require elevated privileges. +Unfortunately, OpenVPN requires privileges to at least configure a tun device. +Our MirageVPN implementation does IP packet parsing in userspace. +We test our protocol implementation, not the entire unikernel - but the unikernel code is a tiny layer on top of the purely functional protocol implementation.

+

We explored unit testing the packet decoding and decryption with our implementation and the C implementation. +Specifically, we encountered a packet whose message authentication code (MAC) was deemed invalid by the C implementation. +It helped us discover the MAC computation was correct but the packet encoding was truncated - both implementations agreed that the MAC was bad. +The test was very tedious to write and would not easily scale to cover a large portion of the code. +If of interest, take a look into our modifications to OpenVPN and modifications to MirageVPN.

+

The end-to-end testing is in addition to our unit tests and fuzz testing; and to our benchmarking binary.

+

Our results are that with 4 configurations we achieve above 75% code coverage in MirageVPN. +While investigating the code coverage results, we found various pieces of code that were never executed, and we were able to remove them. +Code that does not exist is bug-free :D +With these tests in place future maintenance is less daunting as they will help us guard us from breaking the code.

+

At the moment we do not exercise the error paths very well in the code. +This is much less straightforward to test in this manner, and is important future work. +We plan to develop a client and server that injects faults at various stages of the protocol to test these error paths. +OpenVPN built with debugging enabled also comes with a --gremlin mode that injects faults, and would be interesting to investigate.

+ +
+ +
+ + + + diff --git a/feed.xml b/feed.xml index c508c2d..b2b73c8 100644 --- a/feed.xml +++ b/feed.xml @@ -47,6 +47,13 @@ https://blog.robur.coop/articles/tar-release.html Thu, 15 Aug 2024 00:00:00 GMT + + Testing MirageVPN against OpenVPN™ + https://blog.robur.coop/articles/miragevpn-testing.html + + https://blog.robur.coop/articles/miragevpn-testing.html + Wed, 26 Jun 2024 00:00:00 GMT + qubes-miragevpn, a MirageVPN client for QubesOS https://blog.robur.coop/articles/qubes-miragevpn.html diff --git a/index.html b/index.html index ca3a115..6483cf0 100644 --- a/index.html +++ b/index.html @@ -89,6 +89,19 @@ +
  • +
    + + +
    +
    + 2024-06-26 + Testing MirageVPN against OpenVPN™
    +

    Some notes about how we test MirageVPN against OpenVPN™

    +
    + +
    +
  • diff --git a/tags.html b/tags.html index 6cc8340..463ed4f 100644 --- a/tags.html +++ b/tags.html @@ -22,7 +22,7 @@
    Back to index -
    +

    tar

    +