wireguard 入站功能缺失

[Songxwn]

wireguard 入站功能缺失

[alireza0]

@OnceUponATimeInAmerica
Sorry! I didn't answer in this issue.
Yes, based on this thread and #896 , it was tested and deployed.
I hope it could help.
Don't hesitate to inform me if there is any problem or ambiguity.

[OnceUponATimeInAmerica]

Many thanks to Alireza for adding this capability.

It think there might be some misunderstanding in mapping WireGuard features/concepts to those of v2ray/Xray.
My own understanding is that for each node's WireGuard config, its [Interface] section very roughly maps to v2ray's concept of an inbound (how the node listens for connections and authenticates) and its [Peer] section (also very roughly) maps to Xray's outbound object definition (what address and port should it call, etc.).

Therefore, when we use the x-ui panel to create a WireGuard config ("creating inbound"), we are actually creating a WireGuard client-config and ALSO adding a new [Peer] section to server's (already existing) WireGuard server-config.
The UI should automatically generate a single public/private key pair for the new client.

Server's public-private key pair must have been generated earlier (e.g. created in Xray Configs section of the x-ui panel and later used when creating inbounds/WireGuard-clients). In other words, the panel must generate private/public key pair and listening port for the server node only once (as part of its [Interface] section of the server config) and it does not need to show the user, server's private key (only its public key which is copied into client config).

Then later when the panel generates the final WireGuard client-config (to be copied to clipboard), it should (perhaps) use the WireGuard .conf file format. The panel must put in the WireGuard client config the following:

1. Client's private key (generated on-demand by the panel);
2. Client's virtual/VPN address (in its [Interface] section (this address must be unique in server's config and must be added to it as a new [Peer] section);
3. Server's (already generated and fixed) public key and also its (real/physical) address and WireGuard listening port (Endpoint). I am not sure if server's listening WireGuard port should also be fixed (it probably must).
4. AllowedIPs entry in client config is usually 0.0.0.0/0,::/0

Upon creation of the new client config, the panel must also add the following to its own server config (again possibly created from Xray Configs page of the panel):

1. Server config's [Interface] section remains unchanged, of course.
2. A new [Peer] section is added to the server WireGuard config (contained in Xray code config's inbounds array perhaps) with client's newly generated PublicKey and the AllowedIPs entry usually contains the client's virtual/VPN ip4v and ipv6, e.g. AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128 (same subnet as the server's).
3. The use of PresharedKey is optional and must be same in the corresponding Peer sections of both client and server WireGuard configs.

In summary the generated WireGuard config (=copied link) for the end user must contain server's (fixed and not per client config) public key and client's private key; The client's public key must also be added to [Peers] section of the WireGuard server config which is kept at the server (as part of Xray core config).

Also because there are no real clients and servers in WireGuard and just peers, the Wireguard client side should ( in principle) generate their own private/public key pair and provide only the public one to the "server" party; But this is inconvenient in commercial VPN setups and the VPN provider (which operates the "server") usually generates all the keys for all clients (as the x-ui panel should do in this case). The "add inbound" page of the x-ui panel, seems like the logical place to generate the client (end-user) public-private keys. But then, this creates the problem of storing client's private key at the server: It cannot be in the Xray-core config file so it must be somewhere in panel's x-ui.db! (Maybe reuse the unused stream_settings column for that purpose?)

Mapping WireGuard's (asymmetric, peer-based) model to Xray/x-ui's is indeed somewhat difficult but achievable and worthwhile.

ref 1.

I hope I didn't make too many mistakes and sorry for the long post.
Thank you and ممنون.

[alireza0]

@Songxwn Actually it is not true!
Wireguard protocol is a peer-to-peer protocol and not site-client.
But hopefully we can convert it to multi peer configuration with providing link+qrcode.
I should find a standard way for it.

[wulfric93]

it seems that wireguard is only applicable to outbound

[Songxwn]

Thanks to the developer for the answer, you can refer to this project for client access generation.

https://github.com/ngoduykhanh/wireguard-ui

[alireza0]

The concept behinh the Wireguard protocol in xray-core is for tunneling known servers.
Most Wireguard client apps are able to prepare their own key-pair. Therefore client's public key should be stored in wireguard inbound. That means we should prepare client and server together and exchange the public keys.

We cannot expect that peers could play a rule as well as clients in other potocols like VLESS.
By this concept, in my opinion it is not necessary to prepare client's configs in advance.

Wireguard links have two two models: wireguard:// and wg://

I will take a look at other applications if I can convert it to sth like multi-client interface.
Then it is also possible to convert the link in outbound modal.

[Songxwn]

xray wireguard inbound is a site-client function, not a site-to-site function. I feel it is better to automatically generate Peer configuration to facilitate client access.

[OnceUponATimeInAmerica]

I think the issue has been resolved in a pretty straightforward fashion in the latest update and can be closed now. Thanks to Alireza.

[Songxwn]

Thank you very much for the support. I feel that after testing, it can be closed.