41–50 of 57 posts
IPv6. This allows my hosts to be accessible to the internet, even though they're behind routers/NAT devices.
Some pointers for a noob to follow? Thanks in advance.
Zerotier - https://www.zerotier.com/ 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 satu…
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.
https://chrome.google.com/webstore/detail/chrome-remote-desk...
Earlier quoted context omitted.
Also impossible to properly firewall. By design you give the whole world the opportunity to send you traffic to forward. This does not work for any kind of professional deployment.
This depends on what you mean by "properly" and "impossible" and "professional" and "forward". 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 "forwa…
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.
Earlier quoted context omitted.
> 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…
OpenSSH has support for VPNs so you can connect two networks, although they do mention that for permanent VPNs you should use something else.
For VNC-style full desktop access, Teamviewer just works...it runs on Windows and Linux, is very fast, and (usually) doesn't need any special firewall/NAT rules set up. I believe on Windows at least, it can be used to establish a VPN as well. 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…