Yggstack as SOCKS for Internet

[bjtftw]

Hey, how about extending already built-in socks functionality so yggstack would work as a standard socks for Internet? I mean yggstack would listen on it's YGG IP for incoming connections and then forward them to Internet.

Why? Well, on shell accounts with limited user resources like nr. of processes it would be beneficial to reduce number of them. Additionally it would make yggstack nice super simple alternative to v2ray, etc. proxy type stuff so I'm sure many people would be happy :)

Right now I'm using -exposetcp functionality to point to other socks process on shell account but as socks code is already in yggstack it should be trivial to make it work as socks for clearnet also and simplify mentioned scenario a little.

[basilgello]

I think best is to share the same codebase in this repo but build another executable (yggproxy maybe?) so that yggstack binary is not bloated with unrelated functionality but the codebase maintenance is stoll rather simple.

[basilgello]

Also see issue #7

[bjtftw]

Do you think about yggproxy with all the yggstack functionality in it or completely stripped of it minimal only SOCKS related code? Because I'm using -exposetcp also for other things so it would be beneficial to have all this in one process and not separated to classic yggstack for -exposetcp and yggproxy for SOCKS.

Also see issue #7

It looks perguth wants a different thing, if I understand that the proper way, he wants yggstack to serve http content as https so clients don't scream about unsecured connection. So he probably wants -socks functionality to automatically create tls layer for http content from yggdrasil network and serve this as https as no one is using tls on ygg sites.

[basilgello]

Key question for me is:

Suppose we add "exit node" functionality aka SOCKS proxy.

How does arbitrary TCP client connected via yggdrasil (not yggstack!) utilize this functionslity?
How does sysop prevent abuse of this new functionality?

[bjtftw]

How does arbitrary TCP client connected via yggdrasil (not yggstack!) utilize this functionality?

You set socks proxy in your web browser pointing to YGGIP:PORT of yggstack instance? The same as normal SOCKS on IPv6 address.

How does sysop prevent abuse of this new functionality?

1. If you need you can add simple plain text login/password socks authentication as yggdrasil network is encrypted we already have security there.
2. destination IP and PORT ranges filtering (IPv6 and IPv4 as we are thinking of Internet side connectivity here. You want to have default policy choice here like "allow everything except listed" or the opposite "block everything except listed" )
3. List of Yggdrasil public keys allowed to connect to SOCKS port, you can try to readapt "AllowedPublicKeys: []" code to something like "SOCKSAllowedPublicKeys: []"
4. You don't care :)

If you are afraid that it may impact badly yggstack project maybe create separate branch?

[d47081]

Same question here #9

[basilgello]

I was thinking on how can we feasibly use Yggdrasil as clearnet gateway without nginx, wireguard or other solutions like that.

1. IPv6 address access will not be possible because all Yggdrasil IPv6 space is a subnet of all possible IPv6 addresses
2. IPv4 can be done using XLAT: the /96 address block is allocated from /64 subnet belonging to each key (there can be 2^32 such blocks per instance, making it impractical to bruteforce the block start), and all public IPv4 address ranges (excluding 10.0.0.0/8, 127.0.0.0/8, 192.16.0.0/21) are transparently mapped into the block addresses so 1 ipv6 address corresponds to 1 ipv4 address
3. The separate yggproxy binary that can work as a drop-in replacement of yggdrasil (TUN device serving Ygg IPv6 and routable IPv4 space) and yggstack (SOCKS5 or local TCP/UDP port forwarding without TUN) depending on configuration implements the XLAT stuff.
4. If multiple "proxy" ranges are specified on the client side, connections are distributed in a round robin fashion but the target IPv4 address must be mapped to the proxy block to avoid IP address hopping and associated antifraud system triggers.

Security considerations:

1. Only those client and "exit" nides using yggproxy participate in the VPN.
2. Hard-to-guess proxy /96 block start value requires an attacker to perform 4 billion probes to any given IP to find the correct block
3. If AllowedPublicKeys are in place, only those with keys eligible for connection can peer with node
4. Prevention of access to IPv4 local/reserved address ranges (configurable?) protects local machine from hacking attempts

[bjtftw]

OK Vasil, I see things are more complicated than I though they will be, so at this point I don't want to bother you with this issue, as I'm using Yggstack+internetSOCKS already, just as two independent pieces of software (I'm simply using yggstack -remote-tcp 1080:127.0.0.1:1080 to point to socks process) and it works great (the only reason for this issue report on my side was to reduce number of background processes owned by me on remote machine from 2 (yggstack+externalsocks) to 1 (yggstack with socks in one process).

I don't see any point in you being engaged to write so much new code, rethink all the process logic, etc, so I will leave this to you, if you think it's worth to work on this with your implementation than go ahead, code it (maybe as a completely new branch?), and I will help you with testing this, but if you think there's too much hassle with this issue, you can close it as we can achieve this functionality already with help of external SOCKS software, which there are plenty in Linux world, and they are really, really optimized in the sense of code size, resources utilization (like microsocks package in most distros repos) so I don't think it does make any sense of reinventing the wheel.

So that's my point right now, of course Yggstack is a great software even without this :)

[basilgello]

Writing the outline above I've never heard of https://github.com/neilalexander/yggdrasilckr that is exactly what is needed

@bjtftw @d47081