Security
What lnk vpn exit <machine> home exposes, and what it doesn't. How an
agent's traffic reaches the exit, through Link's filtering proxy, is in
the sandbox's security.
What's reachable
-
The exit is an
ssh -Rfrom here to the machine, over Link's SSH to a box (lnk box forward) or your own SSH setup for any other host, to a SOCKS5 server on this computer's loopback, at a free port, while the exit is up (lnk sandbox socks, so the sandbox plugin is needed). -
That server reaches only the internet: never this computer's own addresses or loopback, its LAN, link-local or shared (CGNAT) ranges, a cloud's metadata service, the IPv6 /48 around this computer's own address, where the other devices of its network are, or its network's public IPv4 address, where some routers answer their admin page from inside. It takes addresses only and never resolves a name, so a name can't point it home. A program on the machine gets your home address, not your home.
-
On the machine, the SOCKS5 proxy is a Unix socket in your home folder,
~/.config/lnk/vpn/exit.sock, which sshd makes readable and writable by your user only (StreamLocalBindMask,0177by default), in a folder only yours (700). Your programs on that machine can use it; other users there and nothing on its network can. The proxy takes no password, so this is what keeps others out. No sshd setting opens a socket to the network, asGatewayPortsdoes a port. -
Before each connection, the exit removes a socket a connection before left there (sshd leaves it, and binds over none), over an SSH connection of its own. So of two computers making one machine their exit, the one that connected last has the socket.
-
With
--port, or for an agent on a box whoselnkis from before the socket, the proxy listens on the machine's loopback instead,127.0.0.1:40780, while anyone holds it there. Programs of every user there can use it; nothing on its network can. An exit held from before the socket stays on the port until those holding it there give it back. An sshd withGatewayPorts yesignores the127.0.0.1asked for and opens the port on every address. So on a host that isn't a box, on the port:- Before an exit starts,
lnk vpn exit <host> homemakes the same forward once, to a port here where nothing listens, and checks it. On such a host it refuses to start the exit. A host it can't reach then is left to the exit, which keeps trying. - The exit's SSH connection runs the check there too, through your
login shell: it reads the host's listening ports (
/proc/net/tcp, ornetstat -anoff Linux) and, when40780listens anywhere but loopback, or can't be seen on loopback within 5 seconds, ends the connection by ending its sshd, about a second after it prints why. That ends every connection made through the port too, so holding one doesn't keep the port open. It checks again every 10 seconds, and ends itself when the connection does. - Such a port is open for the moment between sshd opening it and the
check ending it, one to two seconds. That happens only when a host
turns
GatewayPortson after its exit started: then again each time the exit reconnects, every 10 seconds, until you fix sshd or runlnk vpn exit <host> off.
Boxes keep sshd's default,
no, and run no check. - Before an exit starts,
-
An exit started by an
lnkfrom before this proxy used ssh's own SOCKS, which reaches this computer and its LAN. The nextlnk vpn exit <machine> homerestarts any exit whose service differs from what thislnkwould start;lnk agent moveandlnk agent exit homerun it. Until then, such an exit to a box is down, sincelnk box forwardrefuses to run without a proxy to forward to. One to any other host stays as it was: runlnk vpn exit <host> home. -
An agent's proxy on a box reaches the socket by its path; the agent itself can't: every sandbox hides the socket's folder,
~/.config/lnk/vpn, as it hides Link's settings, and whenXDG_CONFIG_HOMEputs the settings elsewhere it still hides that folder (making it when it's missing, so a socket put there later never shows in a running sandbox). -
It needs no administrator rights here or on the machine.
How it learns your public address
When the exit starts, and every 5 minutes, it asks your router with
NAT-PMP, and Cloudflare's STUN server (stun.cloudflare.com) which
address your connections are seen from. Cloudflare sees a request from
your address and nothing else. It refuses both, and keeps the last ones
learned when neither answers.
Who can use your address
Any program of your user on that machine can use your home address while the exit is up, not only your agent; on the port, any program of any user there. Make a machine your exit only if what runs there is yours.
When this computer is off
With this computer off or offline, or the SSH connection down, nothing answers on the socket, or the port, and nothing gets home. An agent routed through the exit then has no internet at all: it fails closed and never falls back to the machine's own network.
Limits
- Your network's public IPv4 address is refused only once learned: with no NAT-PMP on your router and no UDP out to STUN, it isn't. IPv6 devices of your network outside the /48 around this computer's address aren't known to it.
- TCP only, through a SOCKS5 proxy: a program has to use it.
- For a host that isn't a box, SSH runs with
BatchMode=yes, so it must work without typing anything, and the host needs/bin/sh, and on the port either/proc/net/tcpornetstatfor the check above; without them the exit stops. - The socket's path, home folder included, must fit a Unix socket's
(about 100 characters), and the home folder's path is letters,
digits and
/._-+@only; otherwise the exit can't start on the socket: use--port. - A machine's name is letters, digits and
@._:-only, and never starts with-, so it can't be read as an SSH option.
