Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TrustTunnel: AdGuard VPN protocol goes open-source

adguard-vpn.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#61

Post by ameshkov »

xtacy wrote: post #59
ameshkov wrote: post #38

Earlier quoted context omitted.

We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow. And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing. We’re considering switching to it though (or having an option to use it) just to make the server compatible with mo…

> QUIC is not bad, but there are places where it either does not work at all or works too slow. Curious: in your experience where does QUIC work bad/slow?

For example, in some countries it's either slowed down or outright blocked.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#62

Post by mintflow »

stefanha wrote: post #11

Link to the protocol specification: https://github.com/TrustTunnel/TrustTunnel/blob/master/PROTO... It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic. It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!

just did some spec reading, it's quite clear and nit.

I can understand that put UDP payload into a single HTTP stream, at least when QUIC transport is in use, there is no UDP in TCP case.

The Source Address/Port in the UDP payload message serve as key to handle to the tunnel client if I understand correctly?

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#63

Post by eptcyka »

ameshkov wrote: post #60
eptcyka wrote: post #57

Earlier quoted context omitted.

Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.

Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.

Unfortunately, I am no stranger to embedding a whole userspace networking stack into a VPN client either.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#64

Post by DrBurrito »

ameshkov wrote: post #49
DrBurrito wrote: post #48

I like and use your products, so, first of all, thank you! that the protocol was not open was one of my main issues for not using the vpn service,?it is great to see. i look forward for the upcoming audits. one thing i would like to see more is info about the company. the team, the offices, etc. there have been rumors and contradictory infos over the years, and the blog always have a “stock photo”, shady vibe. puttin…

There are no shady alleys in Cyprus:) We have only one office in Limassol, the company is mostly remote: https://maps.app.goo.gl/pounSEQqBvYftZGZ6?g_st=ic (we are moving to a bit bigger office in the neighboring building, no nice photos on google yet) We do not have a dedicated team page on the website, but we’re not hiding our faces, the team can be found on Github. Members of the team often visit AFDS [1] [2], you…

right, thanks! nice to see. note that your legal address in the website points to another address, which is the one I mean. Maybe needs an update:

https://adguard.com/en/contacts.html

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#65

Post by Sir_Burpalot »

Does anyone know if this protocol uses QUIC's RFC 9221 extension in order to eliminate overhead when tunnelling UDP over QUIC? According to their blog post, TrustTunnel does somehow avoid that overhead, but the actual protocol specification doesn't mention anything of that sort.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#66

Post by ameshkov »

DrBurrito wrote: post #64
ameshkov wrote: post #49

Earlier quoted context omitted.

There are no shady alleys in Cyprus:) We have only one office in Limassol, the company is mostly remote: https://maps.app.goo.gl/pounSEQqBvYftZGZ6?g_st=ic (we are moving to a bit bigger office in the neighboring building, no nice photos on google yet) We do not have a dedicated team page on the website, but we’re not hiding our faces, the team can be found on Github. Members of the team often visit AFDS [1] [2], you…

right, thanks! nice to see. note that your legal address in the website points to another address, which is the one I mean. Maybe needs an update: https://adguard.com/en/contacts.html

In Cyprus, companies are usually incorporated via a corporate service provider, who also provides the registered office address and PO Box services. Basically, if you need to reach out to us by mail, you should use the "legal address" from the website.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#67

Post by ameshkov »

Sir_Burpalot wrote: post #65

Does anyone know if this protocol uses QUIC's RFC 9221 extension in order to eliminate overhead when tunnelling UDP over QUIC? According to their blog post, TrustTunnel does somehow avoid that overhead, but the actual protocol specification doesn't mention anything of that sort.

No, but it's a very good point, we'll add it to the backlog

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#68

Post by Sir_Burpalot »

ameshkov wrote: post #67
Sir_Burpalot wrote: post #65

Does anyone know if this protocol uses QUIC's RFC 9221 extension in order to eliminate overhead when tunnelling UDP over QUIC? According to their blog post, TrustTunnel does somehow avoid that overhead, but the actual protocol specification doesn't mention anything of that sort.

No, but it's a very good point, we'll add it to the backlog

Excellent, thanks for the quick response! Are there any plans to add support for full-cone NAT as well, in order to improve compatibility with some games?

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#69

Post by Pesevere »

ameshkov wrote: post #51
rfv6723 wrote: post #43

Earlier quoted context omitted.

In Fujian province, all foreign domains which aren't in white list are blocked. This results that proxy server needs to use a fake sni in white list or ditch https.

This is actually supported by both the client and the server. To use it in mobile clients you need to specify two domain names like that: fake-sni.com|domain.com where “fake-sni.com” is the domain thay will be in the SNI and “domain.com” is the domain in your TLS certificate (used to check the server’s authenticity)

I tried the method you suggested on the Android client, but it doesn't seem to work. After setting the domain name to two domains connected by `|`, the client fails to connect to the server and remains stuck in a “connecting” state.

Is this feature not yet supported on Android?

Post reply on HN