feat(vless): IP restriction #2277
Conversation
Beta, only works for vless for now and it's not perfect needs a lot of testing.
|
@hiddify1 check this out |
|
That is a great job. However, i think it would be better to have also a
gRPC service to retrieve the active IPs. Is it possible to add it?
…On Sat, Jul 1, 2023 at 2:13 AM realartin ***@***.***> wrote:
@hiddify1 <https://github.com/hiddify1> check this out
—
Reply to this email directly, view it on GitHub
<#2277 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/A3HPTEJ5VBPXK5NLLPFI3NTXN5TS7ANCNFSM6AAAAAAZZ3H2C4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Well, that's possible. Currently, the real functionality of IP Restriction is important, then other things like API service |
|
I think, core would not add logic to limit user. Such logic is only useful when tied with user authorization, payment calculation as such. |
@yuhan6665, Why not? it's very useful to avoid sharing configs... |
|
frankly, core is maintained with volunteer time. It is crucial to focus this project. |
Is that mean that this PR is never going to be merged? |
|
@SafaSafari @hiddify1 we need your help to implement this |
Maybe you shouldn't share your configs with others.Many Iranians want this feature because they sell proxies created by xray core, while xray core is not a commercial product.But I also think this feature can be a good option if we wanna share our server with other friends for cost sharing,so any chances to merge this PR? @yuhan6665 also CC @RPRX |
|
The real problem is that when you set up a server with Xray-core and give that vless config to your friend they'll share that with other people and that's a big problem. Of course, this helps proxy sellers but the main goal of this purpose is to avoid config sharing by limiting users by IP. |
|
your service provider doesn't charge by number of connecting IPs right? It seems unnecessary to me. But again, I don't want core to get involved with these business logic anyway |
|
@FranzKafkaYu, Not many people knows how to buy a VPS and setup a proxy, there's always someone that creates one and shares with others to help others access free internet |
Almost all proxy sellers sell configs as subscriptions rather than single configuration, it's clear that this implementation does not provide limitation across multiple nodes and there's no Redis server involved here to help out proxy sellers. |
|
一般来说我们不喜欢加机场专属功能，比如限 IP、限速，虽然 @FranzKafkaYu 找了一个不错的理由， 总之如果这是个 Feature Request，我肯定是不会去实现的，如果这是个写好的 PR，可以考虑一下， |
it's reasonable,but if you share your configs with your friends,you should tell them do not share with others,or it will be blocked.If they shared,you should kick them out.Add this feature may cause some problems:
In principle,core should be tidy and keep core functions for proxy.User management and control should be achieved by other tools.Here if you want to restrict connected IPs,iptables can do this job for you. In my opinion,this feature can be a good option if we share a proxy server with some strangers for cost sharing,but we also can use iptables to make some restrictions. |
|
please consider if we make a config for a few people then those people share the config : |
sir at least make it like an extension to the core , if someone needs it make it on if someone doesn't want to use make it off and the default it can be off tnx a lot ❤️ |
this is not efficient when we have a lot of user we can't control theme 1 by 1 |
for cost sharing : please consider this as a request for so many people and help us let this be an extension 🫠❤️ |
|
where's the core that we can test ? |
The pull request is currently under review and is not yet merged into the main codebase. |
amir-devman
changed the title
amir-devman
changed the title
|
@amir-devman Great implementation. Please do it for us with @RPRX because this feature is a must. |
|
等 @amir-devman 实现了 #2277 (comment) ，这个功能会合并到 v1.9 中 |
|
this feature connecting and disconnecting hooks can solve this issue and more like this |
|
I think the following questions you may consider:
Thank you for your contribution to this project ! |
Fixed a panic on worker.go
Conflicts: common/xudp/xudp.go core/core.go go.mod go.sum main/commands/all/x25519.go proxy/freedom/config.pb.go proxy/wireguard/client.go proxy/wireguard/config.pb.go transport/internet/reality/config.pb.go transport/internet/reality/reality.go
amir-devman
changed the title
|
@yuhan6665 @RPRX, I've done what you requested and also fixed a panic error. |
|
@amir-devman Thank you for your excellent work. Why is Maxips at the policy level? It might be more suitable to place it in the clients section. |
|
@MHSanaei This is what RPRX asked me to do. |
|
LGTM. However, needs to pass some tests before merging into the master branch. |
|
Great job. I need to create a policy with a level. In the level, specify the number of allowed connections. And in clients indicate the level number. Fabulous. Amir, can you make instructions? I want to test your development!!! |
|
please give us example config.json for using limit ip client |
|
@scriptvpskita Example config is in the PR description |
|
Is it useful for proxy panels who give each user multiple type of configs, or when there is multiple proxy nodes available for same user? I think if there was an API to give a list of users with count and IP of active connections, it was more useful for all type of panels and will need no big changes, they must just add a little script to run each minute |
|
No, that's not suited for that purpose, the whole purpose of this is to give people the ability to limit connections per IP to avoid the spread of their config. Also, no one is getting banned, this only prevents people from having access to config with certain IPs per user within the last 30 seconds. so for example, if someone connected and they changed the IP or ISP they should wait 30 seconds before they can connect again. (You can also set the However, you can have a single server as your upstream and multiple other servers as other locations servers and pass all traffic through your upstream server using Xray-Core's routing system, and this can work perfectly with that too. |
|
So it's not useful for panels who support multi-node
Do you know if you be on a bus or train and your phone connect to new antenna automatic, ISP will give you new IP? |
I assume there's a map with a key for each user's email (which must be unique and represent the UUID) and if two users connect with the same IP address, the IP limit should work just fine because there are two independent keys!
If you're on a bus/train/car at high speed, the ISP assigns a new IP address for you. (the period of reassignment depends on the nearest antenna, your speed, the ISP itself, etc... which could be less than 30 seconds), So there might be a small chance that certain IPs trying to connect to the proxy but with this feature, you'll not be able to connect according to the policy limits. This issue comes from the original IP limit idea, not the implementation and there's nothing to do about it. |
Well just change the Idea of IP limit to a better one that not bother the user? I think this is the best way, will benefit all, will have no false positive & will not waste much hardware resources : Xray-core saves connection start time in memory, and continue to count the connection live time (with each keep-alive / new packet) In this way user can connect and disconnect to another server, can do Real Delay test in their clients, change IP as many time as they want, and they will not get banned by mistake, but if 2 people use the same config at same time, they will get detected easily |
yep this is more interesting to do |
|
Hey there, I've used this fork for a while and noticed the core panics when you send frequent requests for a policy with 1 maxIPs via 2 different IPs, so I thought there might be a data race happening in Locking/Unlocking mutex is so important when you use a map, and the mutex protects the map itself not the items on the map. |
|
Hello, are there any updates on this matter? |
|
Is it implemented or no? |
Limits user's connections by number of allowed IP addresses. Simply it closes any other connections if the user exceeds the limit.
The limitation is based on the Email provided for the user
Example
config.json:{ "policy": { "levels": { "0": { "maxIPs": 0, "statsUserUplink": true, "statsUserDownlink": true }, "1": { "maxIPs": 1, "statsUserUplink": true, "statsUserDownlink": true } }, "system": { "statsInboundUplink": true, "statsInboundDownlink": true, "statsOutboundUplink": true, "statsOutboundDownlink": true } }, "inbounds": [ { "listen": "0.0.0.0", "tag": "vless-tcp-reality", "port": 443, "protocol": "vless", "settings": { "clients": [ { "id": "46a9ed35-8c0e-415a-9b5f-12755db8b8cd", "email": "limited-user@example.com", "level": 1, "flow": "xtls-rprx-vision" }, { "id": "aaf2d6f0-e3d0-3840-b59f-1027b6ab14e3", "email": "unlimited-user@example.com", "level": 0, "flow": "xtls-rprx-vision" } ], "decryption": "none" } } ] }Note that, my main programming language is not Golang (I've written this RnD) and I might have written some codes incorrectly. feel free to help me fix it. because I am a super newbie with Xray-Core coding and also Golang.