Ask HN: What do you use for remote access?
Have you ever had to access a device or VM behind NAT and what would you use to do it? Say a raspberry pi running a web server. Would you use port forwarding or something else?
Create a network with automatic IPv6 addresses and start the management access service (likely ssh) on the zt0 interface. then it "just works", regardless of NAT in between.
This is a completely userland solution however. You probably don't want to put real service traffic on it if you care about throughput. It's perfect for management however. (or just test it, maybe you can saturate your link anyway)
This works either by using the public servers for discovery, or you can set up your own dedicated endpoint(s). Either way, the traffic takes the direct route through the NATs, or within the local netowrk if possible.
I was going to suggest something like teamviewer or just a vpn, but this is actually a pretty neat solution that I have not seen before.
I can't say if it is right for businesses, or services, but if you just need to be able to connect to any of your devices, from any of your devices, no matter where you are; then zerotier works wonders.
Sadly I can't seem to get it to compile under OpenBSD.
Might be overkill if you just need to reach one particular service (e.g. HTTP(S)) though, in which case you could consider setting up a reverse proxy (e.g. using nginx) on a DMZ'd server?
I've never set up a VPN and I'm not too knowledgable about them. Should I set one up? I don't know. Toyed with the idea a few weeks ago up until I read this post on StackOverflow (http://serverfault.com/questions/653211/ssh-tunneling-is-fas...) - TLDR (VPNs are slow)
I don't think that's correct. There are multiple kinds of VPNs and multiple things that slow them down. Specifically:
- OpenVPN and other tun/tap handlers send more wrappers and suffer from slow userland networking
- SSH tunneling sends the least amount of unnecessary encapsulation / wrappers
- IPSec, wireguard and other services that do actual traffic processing in the kernel are likely to be faster than the rest, but still has some encapsulation overhead
On a slow link (sending things over internet) the packet overhead matters the most. On a local network, you should be able to saturate 100mbps even with openvpn without a lot of issues.
Out of those SSH is not a "real vpn". There's no persistence and you only get a point-to-point tunnel which needs to be started always from side behind the NAT. Also, you can't connect full networks, or make mDNS work with remote endpoints this way.
> Should I set one up?
If you need just a tunnel that you can set up on demand - probably not. If you need something more - you should definitely try a VPN instead.
Configuring an access server isn't extremely difficult (https://openvpn.net/index.php/access-server/docs/quick-start...)
For anyone wondering about specifics, this is at least how I do it.
* Portforward ssh access through your router to any ssh:able machine behind it.
* Connect with (in my case) putty, under settings -> ssh -> tunnels, set up a dynamic forward with a local port.
* Set up your browser to use a socks5 proxy on localhost:[yourchosenport]
* Browse to whatever local address or name your raspberry has behind that NAT.
* BONUS: circumvents any web firewall you're currently behind since you're browsing from home.
This won't work if the firewall is blocking SSH traffic. Now, if it's just port 22 being blocked, then you setup your sshd to run on something like port 80. At an internship where I had a lot of downtime, I had to setup my sshd to run on 443 since work was blocking pretty much anything that wasn't web traffic. Luckily my domain wasn't on the company URL blacklist.
But it really depends on the use-case. HTTP from behind NAT - that's easy, just port-forward. If you're talking about SSH access, then you have a few more options that you might want to explore (port forward, or tunneling to an external host). If you're talking more than one host behind the NAT, then you have another set of possible solutions (reverse-proxy HTTP servers, SSH gateways, etc...).
Care to give us more information?
If not you'll need to configure a tunnel. You could find this is as easy as installing `miredo`, for example a debian system run:
apt-get install miredo
(e.g. I have IPv6 on my home network, and on my laptop. When traveling I can SSH to my home network via the IPv6 address I've got.)
Just trust me, it works like magic :)
It had the advantage of being quite easy to setup for me as I'm quite used to setup VPNs and NAT forwarding rules (for having living in China, bypassing firewalls is almost an everyday routine exercise :) Also, it worked perfectly well and the performances were reasonable. I could access my server at home, in Beijing, behind a NAT, a dynamic IP and the country's firewall, from anywhere in the world. I was happy!
There are surely other (better?) ways to do it though, and the autossh/reverse tunnels option looks very interesting.
However, assuming this device/VM runs "unix", and to K.I.S.S., use reverse SSH tunnelling. Once an SSH tunnel is established on your side, you can do whatever you want... e.g. tunnel VNC through for GUI.
You can of course add more layers of security e.g. non-standard SSH port, dedicated VM/server for the SSH entry point, refresh SSH keys regularly etc.
Essentially you will add a directive to SSH config for the NAT host, and the host that you want to access. In the directive for the host to access, you will specify that you're proxying through the NAT host.
You can then leave out all of the port forwarding options when connecting to the target host, SSH will pick that up from the config file.
https://chrome.google.com/webstore/detail/chrome-remote-desk...
TeamViewers response was to bury their head in the sand until Ars interviewed them to which they said "none of this is our fault, 2FA is working fine, people being hacked is unrelated to TeamViewer".
In reality TeamViewer wasn't properly rate limiting or blacklisting IP's for making too many guesses at the one-time-password. They made no customer outreach to suggest using 2FA. They didn't acknowledge the attack for 2 weeks until the Ars article, aside from replies to emails saying they should talk to their local police department.
TeamViewer is still the best tool out there for remote access for Windows computers on corporate networks and personal use I find. However their handling of the attack was pathetic.
Many professional name-brand corporations use Tor daily.
The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.
You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.
IP ranges are just another layer of security controls. They may be easily spoofed one way. They may be even spoofed in a two-way communication in some situations. But it doesn't mean it's a useless control. If you can filter more traffic you should and Tor makes that hard to achieve.
> Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Even if you don't participate in the relay of traffic, you're still connecting to the nodes that can send you anything and you need to process it, because it could be traffic addressed to you. I said you may get traffic to forward (or random traffic in general) - it doesn't matter if you're going to actually do it or not. I wouldn't be comfortable running that service. This does not help to reduce your attack surface.
> allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes
It's a tradeoff. You're substituting tested routing mechanism should not be trusted (so we do the AuthN/Z in higher layers), for a relatively new routing mechanism which in duplicates some of the AuthN checking, but at the same time exposes and advertises a new service on your network. You may think it's better, I would disagree.
I built Wormhole Network https://wormhole.network with the idea of making remote access very easy and as secure as possible.
Disclosure: This is SaaS and I've built it.
Wormhole builds an overlay network where you can run any L3 protocol really. By default we provide DHCP for IPv4 within the 100.64.0.0/24 (yes, just a /24 by default as it suits most users, it can be customised or even disabled under request). We have chosen this address space to increase the chances of non-overlapping with your own networks.
The advantage of running an overlay network like Wormhole are:
- No need to open ports anywhere or do any inbound NAT or PAT. All traffic is outgoing. By default UDP, but the protocol would fall back to 443/TCP if needed.
- The above means it works pretty much anywhere with an Internet connection that lets you browse the web.
- Your devices' IP addresses inside Wormhole could be always the same, regardless of where they are. Think of migrating your servers to a new hosting? Keep the same IP. Do you team mates move frequently, work from home at times or even from their favourite coffee place? No problems, they'll keep the same IP address.
- Full access between devices inside the network. It works like a real LAN. No need to open ports to reach out to your development server nor leave any other services reachable from the internet. You could lock down all inbound access from Internet to your servers and still reach them through Wormhole.
- All traffic is encrypted. Note: We don't roll our own crypto. We rely on SoftEther's (see below).
- No need to configure a VPN with your cloud/hosting provider, provision VPN hardware nor anything like that.
- Multiplatorm Linux, Windows and macOS.
- It all runs on free, open source software: SoftEther https://www.softether.org so you can audit the software (and it's not ours, people are using it all over the world for VPN)
The architecture is based on central servers that route the traffic among the peers in your network, hence why full connectivity can be accomplished always with only outbound connections. It is important to choose in which server you want to create your connection, so the latency is as low as possible.
Learn more about us in our documentation section: https://wormhole.network/docs/
We currently have a few hundred users and are looking into making the product better by listening to your feedback. We have a free tier without time or traffic limits, available in three regions (US East, Netherlands and Singapore); it just has user limits. No credit card needed to use it.
I'll be extremely happy to receive criticism, suggestions and any other feedback in general here or directed to pedro /at/ wormhole.network