Viaalink Relay

How Viaalink Relay works

One Relay, an address for every device you own.

Everything that goes through a Relay is one of three kinds of connection. Here they are in plain words, each with a link to the technical details.

Technical details →

Overview

Three ways to connect

A Relay is a server you run yourself. Your devices connect out to it; people reach what you publish through it.

  • A

    Device ↔ Relay

    A client on your device connects out to the Relay and publishes something on that device as an address.

    • One command: via publish 3000
    • Or plain OpenSSH: ssh -R
    • No open port on the device
    How a device publishes
  • B

    SSH client ↔ Relay ↔ device

    A machine publishes its SSH as a private alias. You log in from your laptop with plain OpenSSH and jump through the Relay.

    • Nothing public on the internet
    • Plain OpenSSH: ssh -J
    • The Relay cannot read the session
    How SSH through the Relay works
  • C

    Visitor ↔ address

    Anyone with the link opens the address in a browser. A visitor installs nothing and needs no account.

    • A browser is enough
    • HTTPS on your own domain
    • Optional password per link
    What a visitor sees

Path A

A device publishes an address

A program on your device — the client — calls the Relay, not the other way around.

The device needs no open port and no router rule, only a way to reach the Relay.

The client is the Viaalink CLI (via publish 3000) or plain OpenSSH (ssh -R), which comes with Linux, macOS and current Windows.

While that one connection is open the address works; when it closes, the address is gone.

  1. Your device app on localhost:3000
  2. Client via publish 3000
    connects out · SSH 2222
  3. Relay relay.example.com

Your address https://k3x.relay.example.com

With the default settings the Relay picks a short random name; the client prints the address it got.

Technical details →

Path B

Log in to a machine with SSH, through the Relay

You want to log in to a machine at home or in the office without putting its SSH on the internet.

The machine publishes its SSH under a private alias, a name that exists only inside the Relay.

From your laptop you jump through the Relay with plain OpenSSH; you still log in to the machine itself as usual.

The SSH session runs end to end between your laptop and the machine: the Relay copies the bytes and cannot read them.

  1. Your laptop SSH client (OpenSSH)
    ssh -J
  2. Relay jump, port 2222
    only inside the Relay
  3. Private alias mybox:22
    ssh -R
  4. The machine its own SSH server

One command ssh -J relay.example.com:2222 alice@mybox

Both the laptop and the machine log in to the Relay with an approved SSH key.

Technical details →

Path C

A visitor opens the address

You send someone the address; they open it in a browser. No app, no account, no key.

The Relay finds the device that owns the address and sends the request down that device's connection.

Visitors are not counted as connected devices.

  1. Visitor a browser, nothing installed
    HTTPS 443
  2. Relay HTTPS ends here
    inside the device's SSH
  3. Your device the app you published

HTTPS ends at the Relay, with its Let's Encrypt certificate. To keep strangers out, add a password to one link, or let the Relay accept only certain networks or countries.

Technical details →

The parts

The parts

Four parts, from the app on your device to the person who opens it.

  1. Your app or service e.g. localhost:3000, or SSH
    on the same device
  2. Client via, or OpenSSH
    one outbound SSH connection
  3. Relay on your server, NAS or PC, with automatic HTTPS
    HTTPS on your own domain
  4. Visitor a browser, anywhere

Technical details →

Security

What the Relay can and cannot see

The Relay sits in the middle, so it is worth knowing exactly what passes it in a form it can read.

  1. Visitor browser
    HTTPS
  2. Relay your server
    inside SSH
  3. Your device client

The Relay can see

  • Web requests to your addresses: HTTPS ends at the Relay, because it reads the name to find the right device.
  • Which devices are connected and which addresses each one holds.
  • That someone connected to a private alias.

The Relay cannot see

  • The content of an SSH session through a private alias: it is encrypted between your laptop and the machine.
  • Traffic you publish with TLS passthrough: your own service holds the certificate.

Who proves what

  • Devices and SSH clients log in to the Relay with an approved SSH key.
  • The Relay proves itself to devices with its SSH host key, which OpenSSH checks, and to visitors with its Let's Encrypt certificate.
  • Visitors prove nothing by default; you can add a password per link and IP or country rules.
Whoever runs the Relay could, in principle, read web traffic — that is why you run it yourself. If even that is too much, use TLS passthrough or publish something that encrypts by itself, such as SSH over a private alias.

Technical details →

Step by step

A device connects, step by step

What happens between the moment a client starts and the moment the address works.

  1. Connect out

    The device opens one connection to the Relay's SSH port, 2222. It has five seconds to log in.

  2. Handshake

    The Relay proves who it is with its SSH host key. From here on everything is encrypted.

  3. Log in with a key

    The device proves who it is with an SSH key the operator approved. With a license, the Relay also checks that the device fits your plan.

  4. Ask for an address

    The device asks for addresses with standard SSH forward requests, the same ones ssh -R sends.

    ssh -p 2222 -R app:80:localhost:3000 relay.example.com
  5. Get the address

    The Relay replies with the address it assigned.

    HTTPS: https://k3x.relay.example.com
  6. Carry the traffic

    Each visitor becomes a new channel inside the same SSH connection, and the client hands it to the local app. When the connection closes, its addresses are gone.

Technical details →

Where it runs

Where it runs

Any machine that stays on can be the Relay. Any device can publish through one: it needs only a client, via or OpenSSH.

  • Linux

    Servers, PCs and Raspberry Pi, on Intel/AMD and ARM boards.

    Starts at boot as a system service.

  • Docker

    The viaalink/relay image for amd64 and arm64.

    A container that restarts with Docker.

  • Synology and QNAP

    The same Docker image, in the NAS's container app.

    Runs as a container.

  • ASUSTOR

    The Viaalink Relay app, from the NAS.

    Starts with the NAS.

  • Windows

    Intel/AMD and ARM 64-bit, from a zip file.

    Runs while you are logged in.

  • macOS

    Intel and Apple silicon.

    Runs while you are logged in.

Technical details →

Questions

Short answers

Do visitors install anything?

No. A visitor opens the address in a browser. No app, no account and no key — unless you put a password on that link.

Can the Relay read my SSH session?

No. When you jump through the Relay to a private alias, the SSH session is encrypted between your laptop and the machine. The Relay only sees that a connection was made. Web traffic is different: HTTPS ends at the Relay.

Does every device need a public IP address?

No. Only the Relay must be reachable from the internet. Devices connect out to it and need no open port and no router rule.

Can any device be the Relay?

Any machine that stays on: a Linux server or PC, a Raspberry Pi, a NAS, a Docker host, or a Windows or macOS computer. It needs a domain name you control and its ports reachable from the internet.

Run your own Relay

Start for free, or see what each plan adds.

See the plans Quick start