Related: menshen#7
Background fetching is therefore only possible if the user is not connected to the VPN
current menshen accepts CC as a parameter to allow for this
all good questions!
it seems possible that we're discussing too many things here, and we'd be better by isolating orthogonal problems in their own issues. but trying to answer some:
/service is meant to be there in v5. locations are needed: a) so that user can request gateways for a location of their choice b) because it's the primary override criteria in the UX. c) because we need to put some global configurations there (OpenVPN ciphers, service levels if ever back, custom URLs for vendoring etc).
not needed for solitech tho.
We have a load per gateway and a load for each openvpn process of a gateway
not accurate. load in menshen is a synthetic metric. have a look at https://0xacab.org/leap/menshen_agent/-/blob/main/cmd/menshen_agent/main.go?ref_type=heads#L45
there are a bunch of primary metrics collected, these can be linearly combined to give a float in the [0,1] range.
the current strategy involves differential rates with time dampening, but some simulations with real data will be needed to tweak this.
do note that metrics for bridges need to be carefully considered - since we need to account also for congestion at the target. some naive approach can be to have a multiplicative factor (probl. >0.5) for the destination, and only qualify slightly by the
check latency for all gateways and calculate average
there are several problems with this. first, we don't want to fall back to giving the full public inventory.
imho latency is a good additional heuristic.
what menshen tries to do is give you always the less congested gateway for each location.
then client (bitmask-core) can try to guess what's the nearest gateway in auto mode.
So for example menshen gives us the following information:
I don't think this is what menshen should give, and I've argued against nesting. I think load is essentially per-process (although there's other weight). Extra ports should be given as support but the primary is the port (mainly because the number of clients on that server, which you are ignoring if you aggregate per IP).
what if we can't connect to 2 gateways of a single location
it's quite common to fallback on notifying the user after a certain number of retries and ask them to select a different location.
the danger with putting too many --remotes is that, unless we intervene, the process will keep looping over the same remotes, regardless of current load. This to me speaks strongly for solving the backchannel communication first, and just use whatever is simple for now.
If we have a gateway with 6 listening openvpn ports
I think we've discussed this elsewhere. my bet is, randomize unless there's logic in the client to filter only certain ports (this needs either advanced configuration or storage&inference I think).
For the simple case: just randomize and keep iterating, better more IPs than too many attempts at the same IP.
good question. let's not try to answer it until we get telemetry data.
best strategy IMHO:
We want poeple to use UDP
Yes, let's set it to default. Another option is also, after some # of failures, to incorporate also TCP unless the user has explicitly restricted to UDP only.
The premise of "only by process" does not hold I think. But if there's more UDP load, fine, it's a matter of allocating more processes for UDP.
This should not be a focus for this release tho, I think. We should focus on bridges. It's a platform problem; given enough data, it's the provisioning side responsibility to anticipate load and allocate more resources to UDP ports. We could explore load balancing with a simple UDP proxy.
third party service
for simplicity & resiliency. it might be the case that the provider (ask solitech) wants to incorporate geolocation as an additional service in their API.
looks like this: get location by third party API
the rationale here is linked to the need to refresh load periodically (related: #373)
when user is connected to the gateway, it should retain the original geolocation so that menshen can calculate what would be, in this moment, the best recommended gateway to connect to.
this geolocation can come via geolocation databases from the (non-vpn) IP, but it can be also obtained via other sources (geolocation APIs in mobile, for instance, system inference (like we did in the past with TZ and locales), or a dedicated entry in preferences.
at the end of the day, it's not so important, unless you have many locations. with region (i.e. continent) we've got a good enough approximation.
the other comment related to this: it might be easier to just expose a proxy to menshen in an internal IP in the OpenVPN gateway (to discuss with @sgk as a request for menshen probably).
I've made that change on repository settings already, but just for the sake of keeping legacy branch we can push the same changes and archive master branch
Smaller comment, besides that, looks good to me, thanks!
I would like to set main as the default branch actually. Or maybe you can do that after this one is merged, would be much appreciated.
Aha I knew there was something in float, float/docs/reference.md Doesn't that removes my comment?
All DNS entries are served under an internal domain domain.
the last two commits are force pushed because I messed up the rebase/merge conflict.
Pea Nut (17a7f2c9) at 28 Mar 11:06
Make Bitmask to legacy Bitmask3 struct and move files
... and 1 more commit
@jkito Can we merge this soonish?
Pea Nut (220ffb60) at 28 Mar 10:58
Make Bitmask to legacy Bitmask3 struct and move files
... and 26 more commits
Pea Nut (de9cb544) at 28 Mar 10:48
Improve DNS over HTTPs implementation, fix #7
... and 1 more commit
Yes, I changed the design/workflow of bitmask-core.
Before: call FetchAllGateways() which does not return anything and then call Gateways()
Now: call getGateways() which fetchs and returns gateways
I like this much better. These changes are not yet fixed in the command line tools. That's why they are broken for now. I wanted to show/discuss the changes here before putting work into it.
We can also use the tests for our integration tests instead of cli tools. We just need a running menshen instance (maybe also part of the ci).
There are some TODOs in the MR description. We can discuss, agree and then I can fix the cli tools (+ ci). It's not much work but I don't want to do the work twice.
Hm, we don't need it to be public as we need an API object either. If you look at the tests:
func TestGetGatewaysUnfiltered(t *testing.T) {
api := getTestAPI(t)
gateways, err := api.getGateways(nil)
...
}
Hm you merged !4 (merged). But the commits are not there/squashed. I/Gitlab am confused. Because it still thinks there are 18 commits bewteen this branch an main. But commits like 'Fix call to obfsvpn.client.NewClient()' should/are already merged/fixed by !4 (merged). Not exactly sure how to handle this. If I make a git diff between this (refactoring) and main, it looks good....
Git is magic and sometimes I understand it :D - clicked rebase
and everything is green now :)
we have to merge the float-runner float-runner!3 and we can switch to main