Hacker News Reader

Comment by c7DJTLrn | Hacker News Reader

Definitely interested in this, however:

>Narrowlink uses a centralized gateway that clients and agents connect to over HTTP/S protocols

Tunneling TCP over TCP will undoubtedly result in poor network performance. This is why WireGuard is UDP-only.

Hey, I am the creator of Narrowlink. I certainly find your comment valid, and using WireGuard over HTTPS most of the time provides better network performance. However, in very specific cases, Narrowlink demonstrates superior performance.

1- When your devices' routes are not optimal, and utilizing a CDN can enhance the connection due to smart routing. For instance, I have a server in Poland (while I live in Canada) where the direct connection is slower than connecting via Narrowlink behind the CDN (The gateway behind the CDN).

2- And in rare cases, Tailscale cannot establish a peer-to-peer connection, opting to use DERP servers and their own servers (no longer strictly P2P as seen here: https://tailscale.com/kb/1232/derp-servers/). In such cases, Narrowlink may provide faster connectivity.

3- When you start your Tailscale client, it needs to perform NAT discovery. If a symmetric NAT exists, it takes time to connect due to network flooding for UDP hole punching, while Narrowlink can respond on demand (see the section "The benefits of birthdays" on https://tailscale.com/blog/how-nat-traversal-works/).

It's also important to note, alongside the protocol, the software implementation is crucial. Narrowlink is written purely in Rust, while Tailscale has been created by orchestrating existing tools and uses the Go and C++ programming languages. I suggest you try Narrowlink and experience its computational performance.

I believe Tailscale is an amazing VPN solution, but its protocol, infrastructure, and complexities might not be the best fit for self-hosted platforms. In contrast, Narrowlink is a Proxy solution (currently not a VPN) that is very simple to set up.

Please note that narrowlink only encapsulate the TCP payload's not its headers.

I recently released Narrowlink (just two days ago), and it is in the early stages of its journey. I have various plans for this project, including a web interface, integration of the QUIC protocol, and more. I just need the support of the community and more time to enhance it.

Thanks for the detailed response. Nice work.

Do you have an overview anywhere of the protocol you're using to encapsulate TCP in HTTP? Why did you go with HTTP instead of WebSockets? Does Narrowlink support UDP?

Sorry for so many questions

Narrowlink uses the HTTP/S (WebSocket) protocol as transport; it encapsulates and decapsulates TCP and UDP connections on top of it. This means both UDP/TCP tunneling methods are available out of the box. For example, the following screenshot shows a UDP tunnel for DNS purposes and its encapsulated traffic as TLS (HTTPS+WebSocket=WSS). https://i.ibb.co/wcHB8g2/udp.png

I also invite you to continue the discussion on the github https://github.com/narrowlink/narrowlink/discussions

You are most welcome

Tailsacle also has a series of performance optimization and wireguard testing blog posts; considering some of their late offload additions, and even though they use userspace wg, I find it hard to believe they are nowhere in the same perf ballpark, but I could be entirely wrong here...

They should move to using QUIC which is the protocol backing HTTP/3. QUIC incorporates TLS1.3 and has an extension for UDP style unreliable datagrams (https://datatracker.ietf.org/doc/rfc9221/). It would be the perfect way to bring SSL/TSL/HTTPS VPNs onto a modern performant protocol while keeping the simplicity in of the https based VPN. It would still have the advantage of looking like https traffic, while have the performance characteristics of UDP based VPN protocol.

Isn't SOCKS typically tunneling TCP over TCP? SOCKS has been rock solid for me

And on the other hand, HTTP/S is often using UDP for the transport now

No, because SOCKS terminates the "inner" TCP connection at the proxy.

Reply on news.ycombinator.com