Config file

[aramperes]

As the options will become more numerous with #1 and #2, I think it makes sense to allow a TOML config file to configure the ports and WG tunnel. Something like

[tunnel]
endpoint-addr = "140.30.3.182:51820"
endpoint-public-key = "..."
private-key = "..."
source-peer-ip = "192.168.4.3"
keep-alive = 10
log = "trace"

[ports]

[ports.my-web-server]
source = "127.0.0.1:8080"
destination = "192.168.4.2:8080,192.168.4.4:8080"  # Comma-separated for round-robin
protocol = "TCP"

[ports.my-udp-service]
source = "127.0.0.1:8081"
destination = "192.168.4.4:8081"
protocol = "UDP"

[ports.my-dual-protocol-service]
source = "127.0.0.1:8082"
destination = "192.168.4.4:8082"
protocol = "UDP,TCP"

That could be passed as

$ ./onetun -f onetun.toml

[vi]

Should all features on Onetun be still reachable without using config file, just long enough command line?

E.g. would multiple forwards be still supported file-less?

[cipriancraciun]

destination = "192.168.4.2:8080,192.168.4.4:8080" # Comma-separated for round-robin

Why not make destination a single target option, and introduce destinations that takes a list of targets? (With TCP it's not a problem as , is not allowed as a character. But if one would support UNIX domain sockets, as proposed in #11, then , would be allowed.)

Then inside the code make sure that only one is set destination or destinations and use them appropriatedly.

[aramperes]

@vi

Should all features on Onetun be still reachable without using config file, just long enough command line?

E.g. would multiple forwards be still supported file-less?

I think as much as possible I'd like for those to be configurable from the CLI. If SSH can do it, it should be feasible.

@cipriancraciun

destination = "192.168.4.2:8080,192.168.4.4:8080" # Comma-separated for round-robin

Why not make destination a single target option, and introduce destinations that takes a list of targets? (With TCP it's not a problem as , is not allowed as a character. But if one would support UNIX domain sockets, as proposed in #11, then , would be allowed.)

Then inside the code make sure that only one is set destination or destinations and use them appropriatedly.

That's a good point about UNIX domain sockets. I'm still internally debating the need for , for load-balancing in #10, but I suppose that'll only become a problem when/if both #11 and #10 are implemented.