Support proxy jump #94
Conversation
francoismichel
force-pushed
the
proxy-jump
branch
from
8c379dd
to
50e8a17
Compare
francoismichel
force-pushed
the
proxy-jump
branch
from
50e8a17
to
c43e278
Compare
|
Dropping 1.20 isn't a major problem. If it is we can file changes upstream to remove the new methods they're calling. What's the speed drawback? Is this due to datagram wrapped in a datagram? |
I agree. quic-go always provides support for the last two Go versions. I guess that when quic-go 0.41.0 gets released, these two versions will be 1.21 and 1.22, as it recently dropped support for 1.20. Concerning datagram performance, here is an issue stating the problem: quic-go/quic-go#3766 and the PR quic-go/quic-go#4223 seems to fix that issue, so we should give it a try as well. The problems seems to be due to how the datagram queue was managed. |
| @@ -47,21 +47,24 @@ func homedir() string { | |||
| // If non-nil, use udpConn as transport (can be used for proxy jump) | |||
There was a problem hiding this comment.
This parameter no longer exists
| // If non-nil, use udpConn as transport (can be used for proxy jump) | |
| // If non-nil, establishes a proxy connection towards proxyRemoteAddr first |
| }) | ||
|
|
||
| It("works through proxy jump", func() { | ||
| testUDPPortForwarding(8080, true, &net.UDPAddr{IP: net.ParseIP("127.0.0.1"), Port: 9090}, "hello from client", "hello from server") | ||
| }) | ||
|
|
||
| // Due to current quic-go limitations, the max datagram size is limited to 1200, whatever the real MTU is, |
There was a problem hiding this comment.
How does this work now that we have QUIC in QUIC, is this limit still in place?
|
Because proxy is implemented, maybe good idea to make possible to start ssh3-server without cert/key? In any case, it will be behind reverse-proxy, which one is terminating tls |
|
Not sure I follow here. You typically auth to a proxy even a jump host. It's actually the point of a jump host to act as a bastion with more cumbersome auth than the target |
If users don't need to use their own existing certs, then can start the server using the That being said, I agree with @drewwells. Right now proxy jump is performed by tunneling UDP packets so the connection between the client and the proxied server are still end-to-end, it is just tunneled through the proxy using UDP forwarding. Regarding this PR, I think we can merge it and make it part of the next release, I haven't seen any issues with it yet. |
This PR adds support for classical, secure, UDP-based Proxy-Jump.
Let's say we want to connect from A to C through B, B being the proxy. This works with the client located on A connecting to B and establishing UDP forwarding from towards C. By doing so, the client can send regular encrypted QUIC packets through the forwarded socket to connect to C. B cannot manipulate the QUIC packets are they are encrypted and authenticated.
The drawbacks of the approach are:
So this will work the best for interactive sessions. If troughput is needed, we may want to look at #89 instead.
The current latest quic-go release does not allow to send large datagrams, so this PR is based on quic-go commit 1083d1fb that fixes this problem. I am unsure whether we should wait for quic-go release 0.41 or if we could merge this PR as-is.
Fixes #44