You are reading content from Scuttlebutt
@Hendrik Peter %d6flNRxg+9ljTPAKbWuY0HnhcWKBNhP7NSVxW8vHMyE=.sha256

TL;DR: moving soon, Picoroom and other SSB things I keep online will be gone for a few minutes.

Since I'm moving in a few days to a brand spanking new place on the other side of town I need to make some mods to my pi-servers sitting here at home.

The new place doesn't have fixed IP meaning that whenever the router re-connects the IP address for all my sites changes.
I've considered DynDNS, but using that would imply that the websites/services that I host from home will be offline for a few seconds or even minutes whenever the IP address changes.

So I instead parked a small VPS box with a VPN module somewhere and I'm port forwarding all of my sites to the connected client (works pretty neatly!!).

I'm going to change DNS for @PicoRoom and other sites now, so stuff might be offline for a few minutes. sorry for the inconvenience.

@Hendrik Peter %hLAWsKL4AZolSAOnYQmNjbH1jSJRM9fvtzpfowKlvbU=.sha256

It's done, I'm not super happy with it though. I went the easy route and deployed a Digital Ocean instance in Frankfurt (since that's the closest thing to Sweden they have.
Download speeds and latency are pretty appalling though.

I'm torn between going for a "small" local hosting provider like Banhof, which means keeping track of yet another company that hosts my stuff or throwing the whole thing on an AWS EC2 instance in Stockholm...
I'll go and install a few servers and see what performs best I guess ;)

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@Hendrik Peter %WbDXawLeA4VDmpOvKufKh78fqr4HySq+QaJKylZmzeo=.sha256

@inoas they had data-centers in frankfurt long before they started building infrastructure in the Netherlands.

and I figure they are GDPR compliant.
It's of course up to the owners of the VPC's to make the software they host on their VPC GDPR compliant.

@Hendrik Peter %NGRMFU115mn/kHyIQxBwI6ZpmY25+7RC8AnpRMljyhM=.sha256

*VPS
I'm re-designing some networks on AWS for a client today.. only natural to start mixing VPC (Virtual Private Cloud) with VPS (Virtual Private Server) after a while :p

@Hendrik Peter %bev0t1AvQlaF/Bt0VaVp91JHwioWiBPv7tvY8VIBKvQ=.sha256

I feel ya @Henning Jacobs,

I'm really not a fan of AWS for private stuff (out of nowhere bills and accidentally leftover assets sitting in far away forgotten regions i never check)

I'm sticking with the DigitalOcean IP relay for now. I created a bunch of VPSes and noticed that the ping and speed differences were minimal between them (a 5ms difference).

I actually really love the 5 or so raspberry pi's and the nuc sitting in a drawer here at home keeping most of my sites & infrastructure running. It's bit more of an investment, but I really love the tinkering aspect (especially the northern-lights-sensors kind of tinkering)

@cel-desktop %ZkvCxJY6hsHkqGeaOd3YwE7wlNfHFO/cJHOSeu+cSYE=.sha256

@Hendrik Peter
How do you do the IP relay?
I tried to do something like this, using tunnelling like GRE, but was unable to get it working.

@Hendrik Peter %GY+LomceJyUAgHRd2bYtKr8tL4kU67N7CLeTdYAmzpo=.sha256

SSH

So I started of by just reverse-tunneling in SSH.

You basically put a random VPS somewhere in the cloud, toggle GatewayPorts yes in /etc/ssh/sshd_config and then:

ssh -R 3001:localhost:3001 -R 3002:localhost:3002  user@server

The downside of using reverse tunnels is that SSH is TCP-only. So all my UDP toys remained offline.

OpenVPN

I ended up installing openVPN using the git.io/vpn script, which is super well described in this article by Vivek Gite.

There are some things you need to do after the installation (before rebooting the server):
As long as you use each client certificate on one connected client (so make different certificates by re-executing the setup script for each different connected client) that client will always have the same IP-address assigned to them.

Connect your first client, then with that client connected execute sudo systemctl stop openvpn@server on the VPN server. ending the server process will create a file /etc/openvpn/server/ipp.txt which contains (and locks) whatever clients were connected to that IP-Address.

Toggle port-forwarding on on the VPN server by executing

sudo sysctl net.ipv4.ip_forward

Reconnect your first VPN client and add your first port-forwarding rule (make sure to put all the port forwarding rules in a txt file somewhere since you need to execute the exact same command (replacing the -A with -D) to remove these forwarding rules later.

sudo iptables -t nat -A PREROUTING -p tcp -d "your-vpn-public-ip" --dport 80 -j DNAT --to-destination 10.8.0.2:80
sudo iptables -t nat -A PREROUTING -p tcp -d "your-vpn-public-ip" --dport 443 -j DNAT --to-destination 10.8.0.2:443
sudo iptables -t nat -A PREROUTING -p tcp -d "your-vpn-public-ip" --dport 8008 -j DNAT --to-destination 10.8.0.2:8008
sudo iptables -t nat -A PREROUTING -p udp -d "your-vpn-public-ip" --dport 8008 -j DNAT --to-destination 10.8.0.2:8008

(where 10.8.0.2 is the default address of the first connected client)

The first 2 on this list are your default port 80 and 443 web ports, the last 2 are an example for ssb-rooms
then if you want to add a port-range to your VPN-client MOSH server you can add (where port 1875 is the example ssh port of your client):

sudo iptables -t nat -A PREROUTING -p tcp -d "your-vpn-public-ip" --dport 1875 -j DNAT --to-destination 10.8.0.2:22
sudo iptables -t nat -A PREROUTING -p udp -d "your-vpn-public-ip --dport 60000:61000 -j DNAT --to-destination 10.8.0.2:60000-61000

After you've added your Port forwarding rules make sure to store the basic-vpn rules that were added in the installation as well as your custom port forwarding rules in a permanent store (iptables are wiped between reboots):

sudo apt-get install iptables-persistent
sudo -i
/sbin/iptables-save > /etc/iptables/rules.v4
exit

From here you can go 2 paths when it comes to "masquerading" each option here has its advantages and disadvantages:

If you want the client that connects to the VPN to download data and connect to the internet outside of the VPN (so browse the internet, download data and system updates without tunneling it all through the VPN) then you can execute:

sudo iptables -t nat -A POSTROUTING -j MASQUERADE
sudo -i
/sbin/iptables-save > /etc/iptables/rules.v4
exit

If you do this, then all incoming packages of internet traffic get rewritten to have the source-ip of your VPN server.

Then on the client-side open the certificate and add the following 2 rows:

vpn-bigloop.png

This first line will turn all traffic tunneling off and then the second line will emit all traffic from the VPN internal network back into the VPN internal network.

There are 2 drawbacks with this solution:

  • Since package headers are rewritten all traffic sources are 10.8.0.1. This will hurt if you rate-limit (ssh access for example) by ip-address.
  • If you port-forward 80 and 443 and turn on MASQUERADE on, then the VPN server itself won't be able to download stuff anymore. so you need to turn masquerade off (and hit your connected clients with extra down-time) every time you want to perform system updates.

If you're okay with routing all client traffic through the VPN

then do nothing or turn POSTROUTING -j MASQUERADE off and revert the changes to your client config.

The drawback here is that everything your client does on the internet will add some extra strain on your VPN connection and system updates on the client side will be a bit slower since you're dealing with the extra hop.
(I've chosen this option for my VPN, since I do like to rate-limit ssh attempts, etc.)

User has not chosen to be hosted publicly
@Hendrik Peter %tNfWj3wA/kyyjlTsemMh+R9Y6jkfEyVuIYpMnqyGcw8=.sha256

@cel ^

@Hendrik Peter %hv80NQMI1Cn82v9pA88bWtem1bc56LiENcRzYnlq39U=.sha256

... messed that up @cel-desktop
completely forgot to mention you in my answer ;)

@cel-desktop %eknWnHEWTkHenGbezeaZj5eKELgUCnaANF4iWLof/Cw=.sha256

Thanks, @Hendrik Peter!

Join Scuttlebutt now