alireza0 / x-ui

xray panel supporting multi-protocol multi-user expire day & traffic (Vmess & Vless & Trojan & Shadowsocks)
https://t.me/XrayUI
GNU General Public License v3.0
3k stars 476 forks source link

Check for duplicate socket instead of duplicate port on inbound creation #370

Closed PatrickstarWritesCode closed 10 months ago

PatrickstarWritesCode commented 1 year ago

Is your feature request related to a problem? Please describe. It is not possible to create multiple inbounds on the same port when you are using different listening IPs. I use HAPROXY for SNI routing. I'm trying to create two inbounds on 127.0.0.2:443 and 127.0.0.3:443 but the panel would not allow me. The reason I'm trying to use 443 on both inbounds is for using subscription. If I don't use 443 then the subscription would generate a wrong configuration.

Describe the solution you'd like The ability to create multiple inbounds for the same port given that listening IP is different, in other words make the panel check for IP:PORT combination instead of only PORT.

Describe alternatives you've considered Another solution would be to make a change so that subscription can give another port not the actual port defined in config like how the domain field works at the moment.

Additional context

image
X-Oracle commented 1 year ago

I agree . although it is possible in xray config to have multiple inbounds with same port but listening on deferent ips. but not possible in panel because of outside port checking.

I suggest if checking duplicate socket is not possible or hard to implant , then at least make it to check if the port and listen address is the same instead of only port.

alireza0 commented 1 year ago

One of the important facts which you should consider is that the port is not anly for openning network port. But also for naming the inbound tag inbound-<port> which is developed by the primary developer. Any change in this part will cause several problems in other's usages.

X-Oracle commented 1 year ago

oh right I forgot about it .

what was the principle of doing inbound-{port} when ports can be changed any time by admin ? it is not standard. it must be changed at one time if not it can be a problem for adding new features of x-ui or even xray at some point.

well, what x-ui functions use it ?( I mean if pattern changed those function will break)

if it is none

then we can change the new inbounds name easily.

new pattern would be : inbound-{inbound-id }

if it is few

then we would consider changing them so these x-ui functions won't break.

then we can update installer so it changes database so the old inbound names changes to new pattern when upgrading from versions older than this change.

if it is a lot

then holy moly , it will be a big project. 😂

alireza0 commented 1 year ago

I knew this structure related problems before, but my concerns are more about consistancy. This unnececary complexity is not important for all users. Personaly, I recommend advanced users to use xray configuration instead or applying auxiliary applications like nginx.

X-Oracle commented 1 year ago

Hi thanks for reply.

Regarding Nginx , it still needed for advanced users if want to fall back to grpc or webserver camouflaging.

For some of my users Wich can access ipv6 and have better connection than ipv4 is problematic. Having a config in deffrent port other than 443 , 80 will make the server more likely to be blocked and I don't want to go in a processs of finding a clean ip if i ever find one.

So having 2 or more configs which listen to same port but different ips is much better in case of camouflaging.

Well these are just on the paper . And I know it is hard to dig in an old code considering it was not written by yourself. but if you were free consider fixing it.

Much appreciated.

alireza0 commented 1 year ago

I will do so and keep it in my mind if I could find a solution.

PatrickstarWritesCode commented 1 year ago

How about the alternate solution of faking the port? As far as I understand the domain name field in inbound definition is for generating the final configuration. Is it possible to implement a change in which if a port is identified at the end of domain name, the final config would override the actual port? I'm not proficient in development sorry if the ideas are absurd or not practical in terms of development. Just a network engineer who had to become an amateur DevOps thanks to censorship

linehman commented 1 year ago

Hi thanks for reply.

Regarding Nginx , it still needed for advanced users if want to fall back to grpc or webserver camouflaging.

For some of my users Wich can access ipv6 and have better connection than ipv4 is problematic. Having a config in deffrent port other than 443 , 80 will make the server more likely to be blocked and I don't want to go in a processs of finding a clean ip if i ever find one.

So having 2 or more configs which listen to same port but different ips is much better in case of camouflaging.

Well these are just on the paper . And I know it is hard to dig in an old code considering it was not written by yourself. but if you were free consider fixing it.

Much appreciated.

I use nginx sni routing to redirect all port 443 traffic to different local inbound ports. This way it's not nessesary to create multiple inbounds in x-ui with the same port. I believe this can also be used for multiple IPs by using different dns records for each ip and redirecting them to designated local ports with nginx. check out the following link for more info.

https://github.com/lxhao61/integrated-examples

PatrickstarWritesCode commented 1 year ago

Hi thanks for reply. Regarding Nginx , it still needed for advanced users if want to fall back to grpc or webserver camouflaging. For some of my users Wich can access ipv6 and have better connection than ipv4 is problematic. Having a config in deffrent port other than 443 , 80 will make the server more likely to be blocked and I don't want to go in a processs of finding a clean ip if i ever find one. So having 2 or more configs which listen to same port but different ips is much better in case of camouflaging. Well these are just on the paper . And I know it is hard to dig in an old code considering it was not written by yourself. but if you were free consider fixing it. Much appreciated.

I use nginx sni routing to redirect all port 443 traffic to different local inbound ports. This way it's not nessesary to create multiple inbounds in x-ui with the same port. I believe this can also be used for multiple IPs by using different dns records for each ip and redirecting them to designated local ports with nginx. check out the following link for more info.

https://github.com/lxhao61/integrated-examples

SNI routing and having multiple services is not the issue. The issue is about the subscription service giving away the original port defined in the inbound configuration. Using the same port on all inbounds is solely a workaround of this.

linehman commented 1 year ago

Hi thanks for reply. Regarding Nginx , it still needed for advanced users if want to fall back to grpc or webserver camouflaging. For some of my users Wich can access ipv6 and have better connection than ipv4 is problematic. Having a config in deffrent port other than 443 , 80 will make the server more likely to be blocked and I don't want to go in a processs of finding a clean ip if i ever find one. So having 2 or more configs which listen to same port but different ips is much better in case of camouflaging. Well these are just on the paper . And I know it is hard to dig in an old code considering it was not written by yourself. but if you were free consider fixing it. Much appreciated.

I use nginx sni routing to redirect all port 443 traffic to different local inbound ports. This way it's not nessesary to create multiple inbounds in x-ui with the same port. I believe this can also be used for multiple IPs by using different dns records for each ip and redirecting them to designated local ports with nginx. check out the following link for more info. https://github.com/lxhao61/integrated-examples

SNI routing and having multiple services is not the issue. The issue is about the subscription service giving away the original port defined in the inbound configuration. Using the same port on all inbounds is solely a workaround of this.

That's right. Overall the subscription capabilities of this panel is very basic. But I guess unless the panel has built in support for nginx, it's going to be troublesome to make sense of these custom configurations. However I believe the ideal solution is having a custom subscription bot to achieve all the needed functions. Unfortunately there is not any good ones available now.