Repository navigation
Bill a REALITY client to a SOCKS user, so its tier applies - #18
Merged
Merged
Conversation
Every REALITY session was handed to the SOCKS5 port on the service's shared
credentials, so no tier, limit, counter or byte ever applied to REALITY
traffic. A paying customer's front door and a free one's looked identical
from here, and neither was metered.
xray routes by the email on the VLESS client, so each linked client gets an
email, a socks outbound carrying its own credentials, and a rule joining the
two. Its sessions then arrive as an ordinary user and inherit the whole
pipeline. Clients that are not linked fall through to the shared outbound,
so nothing changes for anyone who has not asked for it.
The credentials are derived rather than stored, which is the part that made
this safe to do alongside password hashing. xray needs a readable password,
the users table must not hold one, and a per-install secret satisfies both:
it is generated once, the username and password are recomputed on every
render, and only the hash is ever written. Nothing readable is kept.
Verified end to end against real xray: a session through a linked client
arrives authenticated as its own user, on its own tier --
connecting to target client=127.0.0.1 user=xr1 tier=free target=api.ipify.org
The test asserts the same chain without a network: the link is recorded, the
user exists at the tier asked for, the derived password verifies against the
stored hash, the rendered config carries the email, the per-user outbound
and the rule, and xray itself accepts that config. Unlinking puts the
client back on the shared credentials.
The cost is stated in the README rather than left to be discovered: each
linked client adds an outbound and a rule, so a very large number of clients
makes the config big.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 47 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gap
Every REALITY session was handed to the SOCKS5 port on the service's shared credentials. No tier, limit, counter or byte ever applied to REALITY traffic: a paying customer's front door and a free one's looked identical from here, and neither was metered.
What it does
xray routes by the email on the VLESS client, so each linked client gets an email, a socks outbound carrying its own credentials, and a rule joining the two. Its sessions then arrive as an ordinary user and inherit the whole pipeline — tier, limits, accounting, the user list. Clients that are not linked fall through to the shared outbound, so nothing changes for anyone who hasn't asked for it.
The part that made this safe
xray needs a readable password in its config; the users table must not hold one, since PR #11 started hashing them. A per-install secret satisfies both: generated once, the username and password are recomputed on every render, and only the hash is ever written. No readable password is kept anywhere — including in git, which is where a hardcoded one would otherwise end up.
Verified end to end, against real xray
A session through a linked client arrives authenticated as its own user on its own tier, where before it arrived as the shared credentials.
The test asserts the same chain without needing a network: the link is recorded, the user exists at the tier asked for, the derived password verifies against the stored hash, the rendered config carries the email, the per-user outbound and the rule, and xray itself accepts that config (
xray run --test). Unlinking puts the client back on the shared credentials.Design notes
Cost, stated rather than discovered later
Each linked client adds one outbound and one rule to the xray config. A few hundred is fine; beyond that this wants rethinking rather than growing. It's in the README.
gofmt/go vetclean; full suite green with and without xray;-raceclean.