Thomas Eizinger 95219376b9 test(connlib): assert connection intents using property-based state machine test (#4597) ...

Opening this in a basic version that asserts sending of connection
intents to resource IPs. To do this, we add some boilerplate that sets
up the state machine test in general. Together with the
[work](d575dc3866/rust/connlib/snownet/tests/lib.rs (L296-L824))
that I've done on the `snownet` tests, this can then be extended to
describe the entire state machine of connlib and letting `proptest`
search for inputs & combinations that break stuff.

Some more `Transition`s that I'd expect we can implement:

- Add DNS resource
- Reconnect (i.e. roam networks)
- Remove resource

The public API of `Tunnel` isn't actually very large: We add and remove
resources, set upstream DNS servers and call `reconnect`. I think the
bet here is that we can implement the reference state machine in a very
simple way. For example, once we have added a resource and handled the
connection-intent, we should be able to send an ICMP packet through the
tunnel. I've already worked out how to pass `Transmit`s back and forth
between relay, client and gateway (see linked `snownet` tests above). If
we port that to this state machine test, we can actually exercise all
the code paths that are required to encapsulate / decapsulate those
packets whilst asserting against something simple like "packet pops out
at the other end".

Because the setup of the test is also a proptest-strategy, we can even
add the network topology as a variable by configuring the `Firewall`
(see `snownet` tests) dynamically with or without blocking rules and
thus force the entire tunnel through an (in-memory) relay.

Related: #4589.

2024-04-19 02:31:08 +00:00

..

src

test(connlib): assert connection intents using property-based state machine test (#4597)

2024-04-19 02:31:08 +00:00

Cargo.toml

fix(windows): patch some DNS leaks (#4530)

2024-04-15 21:10:30 +00:00