fix: server address cannot be network address

[pgalonza]

This solves the issue #1384

[outspace]

@pgalonza thanks!
You did a great job.

Server VPN subnet can be changed from client GUI. Please check that subnet in VPN server config and GUI is the same.

[pgalonza]

@outspace

In this case, the subnet address and wireguard server addresses in the tunnel are different things. Unlike OpenVPN, where the value of the parameter is the subnet. We can also consider the question from another side and change the parameter name in the GUI and make sure the address of wireguard interface doesn't start with a subnet address.
subnet address: 10.8.0.0/24
wireguard(server) address: 10.8.0.1/24
peer address: 10.8.0.2/24 and etc.

My solution is simple and only works when the subnet starts with zero(as it is now by default).

I agree, the parameter can be changed in the GUI and it works without in most cases.

[outspace]

yep, this field called "VPN address subnet" but it's just a AWG/WG server address.

I think, that better to make changes in GUI and change a default parameter from "10.8.0.0" to "10.8.0.1".
In GUI we change field name and add some check for parameter correctness.

[pgalonza]

@outspace thenk you. I am very glad of the discussion.

[pgalonza]

yep, this field called "VPN address subnet" but it's just a AWG/WG server address.

I think, that better to make changes in GUI and change a default parameter from "10.8.0.0" to "10.8.0.1". In GUI we change field name and add some check for parameter correctness.

Do you have any objections if I display this in my issue?

[outspace]

feel free to do it in this PR.

[pgalonza]

yep, this field called "VPN address subnet" but it's just a AWG/WG server address.

I think, that better to make changes in GUI and change a default parameter from "10.8.0.0" to "10.8.0.1". In GUI we change field name and add some check for parameter correctness.

I have studied the project more thoroughly and realized that we will need both a server address for the Wireguard interface and a subnet address for the iptables rules. Unfortunately, I am not well-versed enough in the codebase to make changes to take this into account, other than as a temporary solution suggested earlier. Perhaps in the future, I will be able to adapt and propose the correct changes if they have not been made by another contributor.