-
-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
technical documentation #11
Comments
A complete technical documentation will be made when technical part will be finished :) |
of course, I'm just very interested, and don't understand all of this. |
Hi @Ysurac , I change from #27 to this thread, as you pointed.
Ok. So as an overview this is the current architecture?
Please, correct me if something is wrong! Then, my problem is to understand the Layer 3 architecture. Please, help me to clarify these issues:
I'm trying to undertand the global architecture. 😕 |
It's current architecture.
|
Hi @Ysurac , Thank you for clarification! 😄 Then at time all traffic goes over TCP and through the multiple ShadowSocks connections. In this case, I have some ideas that perhaps you like to consider:
I hope you like to consider these ideas. |
Why would I use redsocks ? It's using TPROXY for UDP. |
For second point, you mean to add a HTTP proxy and socks5 proxy available to lan connection ? Socks5 proxy port can already be open using the firewall. |
Hi @Ysurac ,
The user case is when the WAN-x connection is over a TUNNEL or VPN. So, please implement the option for Shadowsocks without encryption.
Sure! For this reason I suggest to use tunnels or udp-based-vpn's for the underlaying transport.
Great! I prefer to have one (or more) udp channels for UDP traffic; and only force UDP-over-TCP as a last change.
Only in case of UDP-over-TCP.
Yes! For regular WEB traffic (even HTTPS), that is HTTP proxy, will be preferable (more optimized) to execute a local NGINX that uses SS-MPTCP enabled to reach the VPS server, instead of a direct SOCKS5 proxy. No? And for the DNS server, I suggest to replace the current Unbound to a pure DNS server with TCP/HTTP support. For example, see the DNSCrypt Proxy (https://github.com/jedisct1/dnscrypt-proxy). Then you can configure it to use all the time the TCP transport for reach a remote DNS server. You agree? |
|
Hi @Ysurac ,
This will depends on the type of TUNNEL or VPN used. When using UDP or GRE, or similar protocol, as the encapsulation underlaying protocol, then I'm sure no problem will appear when the correct MTU value is used. So, please keep the option for use the configured MTU value in each path.
Sure! So the idea is let the user to select if use UDP over MPTCP all the time; or select one path for routing UDP. And in this last case, I suggest to use a priority method: path 1, path 2, path N. This will be more versatile.
OK.
This depends. But in any case, if you leave the option for runing one Nginx server in the client side, then you leave to the user the option for using it or not. You can redirect all TCP traffic over the Socks5 server, but leave the option for serving proxies (HTTP & Socks5) in local address. You agree?
And this is my request! Leave the user to choose what DNS server use in the client side. If you can, please leave the option for install 3rd party DNS resolvers. For example, I prefer to use DNSCrypt and route all DNS traffic over TCP. Another time, you agree? Thank you for this great project! 😄 |
|
Yes, I see it. Thank you!
If you route UDP traffice over the VPN, then Glorytun (as I feel) is using multipath in the sense of "best ROT path".
I'll explain more: I like to use this project as a "secondary" router. That is, not as my "primary" router. In the configuration of my stock primary router I have a secondary default gateway upstream route that is the OpenMPTCPRouter (configured with one IP address in my LAN segment that isn't the default gw address). And this "secondary default gateway route" in my primary router has a higher cost. So, in a regular state, my LAN traffic goes to my primary router and reach the Internet using the default connection. But, when the default connection goes off (manually or automatically), then all LAN traffic goes to the primary router and it forwards all the traffic to the OpenMPTCPRouter, that then routes all the traffic over the multipath connection to the VPS. In this scenerio, when the default connection is ON, I like to maintain the use of the OpenMPTCPRouter with explicit PROXY connections. That is, the LAN IP of the OpenMPTCPRouter needs to serve the SOCKS5 (1080/TCP) and HTTP (8080/TCP) proxy ports. This is the main reason for one HTTP proxy in the client side. It's sufficient to run one Nginx in the client side using the SOCKS5 proxy. That's all!
Great! This will be sufficient for me. Only remember to leave the option to enable/disable included services (for example the stock DNS server); or at minimum the option for running it in a different port. Regards. |
|
Not really! If your underlaying pathes are encrypted (using tunnels+encryption), then it has sense to disable encryption in the ShadowSocks side. But this is then only true for TCP traffic. All UDP (plus incoming forward traffic) is encrypted using the Glorytun VPN. This is the reason for disabling the encryption in the VPN.
OK!
So, then I only need to run DNSCrypt in 5353 and it will be used. Great! And all 53/UDP (and 53/TCP) will be transparently routed to the DNS server in the 5353 port? Yeah! 😄 |
Why would you use a VPN if you already use tunnels+encryption ? VPN over VPN ? In this case don't run glorytun and configure the already running VPN. Dnsmasq forward all requests, but this can also be configured in the LuCI interface where you want, even on a server listening on another ip. |
I try to explain it:
This has sense for you?
That's a perfect solution! 👍 |
The default route is always set to master or, if master down, to a working path (if any). This feature is not lost when glorytun VPN is down. Traffic will use default route, and if already encrypted no need of glorytun for that. |
Yes, but please review the "mud" project description: https://github.com/angt/mud So, when using the Glorytun VPN you use the best path for such UDP/ICMP traffic, and not the "master" route. And if you don't use at all then VPN, then you lost this function. Futhermore, you lost the Forwading TCP functionality. Why then not have the "option" for disabling the encryption with Glorytun? Regards. |
The version of glorytun used by OpenMPTCProuter doesn't use mud. Mud is used by the UDP version. Glorytun TCP with encryption can be used inside a tunnel, this will really not have big speed impact. |
Then, this is the reason to have a better documentation! Open-MPTCP-Router uses:
|
Hi @Ysurac , Regarding the use of Glorytun...
I ask this because the use of encryption has a very high impact in performance. And when using it with already encrypted tunnels, in this scenario it's completly useless. |
As I already said, documentation will be done for OpenMPTCProuter 1.0, it's alpha version for now. All may change before stable version.
Glorytun:
You make some test of chacha20 encryption impact ? And it's only for ICMP, who care ? |
Hi @Ysurac ,
I know. So, I only like to comment here my experiencies with this project. Don't worry. Regarding the current implementation:
It's this true at time? My suggestion is to replace this current "in-App-custom-Protocol" model with a "layer-level" model. For example:
Then as for the Application level:
And regarding the TUN device:
And why the IPIP protocol? Because if you use Glorytun as a simple "tunneling protocol" (without NAT) then you can use this simple protocol for setup the TUN device. This is lightweight, doesn't use encryption and it's native in OpenWRT. And regarding the option of a custom option for setup the TUN device this will leave to the user the option for use any VPN solution that s/he likes to use.
And it can be a great solution when using only MPTCP transport. But, think on this: imagine that you like to route some protocol (like SIP) over UDP in one path only, and other protocols (like UDT) over the Glorytun MPTCP. If you use this "layer-level" model then the user can select over wich transport protocol route each service. In fact, perhaps you will need to support more than one TUN device (tun0, tun1, tun2, etc.) and the user can then "map" each non TCP service to the prefered TUN device. And then, the "tun0" can be using the Glorytun-TCP, the "tun1" the Glorytun-mud, the "tun2" the IPIP tunnel, etc.
I care when routing other protocols that aren't not TCP. At time, the user can't control wich services use UDP-over-MPTCP or not. Futhermore, when using the TCP Incoming Forwarding all the time the Glorytun is used... and as the encryption is enforced... for an incomming SSH connection... over a tunneled already encrypted connection... you will end with a three-encryption-layers. A waste of resources! I hope you like to thing on this approach... even if you doesn't like it! Perhaps you can found a better solution. |
This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Can you write a little technical documentation, or maybe a schema explaining how it works, what are software used for ?
The text was updated successfully, but these errors were encountered: