Unify hopping and regular API
- May 14, 2024
-
-
Maxb authored
-
Maxb authored
They modify shared state and could theoretically be called concurrently so we can pretty simply protect them w/ a Mutex
-
Maxb authored
It seems like we're having CI failures related to running docker-compose in parallel across multiple integration-test types. Let's see if setting a project name will fix this
-
Maxb authored
We want the client to have a unified API rather than being a socks server for "regular" mode and a transparent UDP proxy for "hopping" mode. We chose to move to the transparent UDP proxy because socks+UDP support is missing/not particularly reliable. On the client side it's simplest for the "regular" mode to be conceptually a "hopping" client that only has a single IP+port endpoint and doesn't bother to ever "hop" to any other endpoint. In that way we can go ahead and remove the other code path. On the server side we do a similar thing, renaming the "HopServer" to "UDPServer" and depending on whether hopping is enabled we listen on a single port or many. We leave the TCP server for now because [our introducer code] (https://0xacab.org/leap/bitmask-core/-/blob/289bd400ef9052c633a1d21f05fefe482ebf11c8/pkg/introducer/httpClient.go?ref_type=heads#L39) uses the obfsvpn.NewDialerFromCert method to create a dialer which depends on an obfsvpn server endpoint running on TCP mode. Note that the client API (and FFI API) have changed so any upstream libraries need to reflect those changes. ALSO: the openvpn client config has changed, including the protocol, the remote, and the removal of the socks parameters.
-