astrogate

Astrogate

Astrologue uses the Yggdrasil network as a backbone of some of its peer-to-peer infrastructre. Astrogate allows configuring gateways that can forward traffic from the clear internet onto the Yggdrasil network and vice-versa following a simple configuration.

Currently supports forwarding the following protocols:

• HTTP unencrypted HyperText Transfer Protcol
• TLS raw Transport layer security, when SNI is present
• XMPP eXtensable Messaging and Presence Protocol
• Astrogate Dial simple header that can be passed at the start of a stream to connect (or "dial" into) a hostname
• HTTP-01 Well Known intercept and redirect HTTP requests for the /.well-known directiory used by LetsEncrypt

When a connection is made to the Astrogate server, it reads data from the client, and uses pattern matching to determine what protocol the client is likely talking. It uses this information to attempt to read out an intended hostname from the data and tunnels the connection to the configured host.

It also supports tunnel mode, where by using the astrogate-tunnel client program creates a TUN interface where traffic will appear to be routed from their original IP addresses on the internet. This is useful since Astrogate does not modify any data it proxies, so there is not (for example) an HTTP X-Forwarded-For header for the server to know where the request came from.

Possible stretch goals

• Raw TCP forwarding (port forwarding) without hostname check
• Support for UDP datagrams and similar port forwarding
• Support IPv6 in the tunnel virtual network (can still currently be hosted over IPv6)

Technical limitations

HTTP and HTTP over TLS

This will work perfectly fine for HTTP/1.1 requests. Things get more hazy when it comes to technologies like streaming connections and HTTP3/Quic for example. Some of these new technologies will be "smart" about whether a connection is going to the same IP address (not just same host) and re-use an existing connection to that same IP. That means that if there are multuple HTTP/HTTPS destinations to reach via the one Astrogate server, servers with this technology enabled may receive requests intended for other domains under a special set of circumstances.

This can be mitigated by not enabling these technologies on the server side.

Tunnel limitations

The tunnel, along with the astrogate-tunnel client (ab)uses the Linux network stack to allow incoming connections to be routed through the tunnel for their lifetime. This means the IP routing table is constantly updated, with specific routes for specific IP addresses added and removed as needed. This could be disruptive to services running on the the client that are expected to be able to initiate connections to IP addresses that may connect to it via the tunnel.

The tunnel acts as a sort of "reverse NAT", except connections from the internet get mapped instead of connections to the internet. This means that the tunnel client can't be used to initiate TCP connections to the internet through the proxy server. This makes it only useful to expose services that accept TCP connections (such as HTTP, Gemini, or Spartan servers) to the internet, not services that need to initiate connections (such as XMPP server-to-server communication for example).