this post was submitted on 15 Jun 2023
12 points (100.0% liked)

Self Hosted - Self-hosting your services.

11223 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules

Important

Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!

Cross-posting

If you see a rule-breaker please DM the mods!

founded 3 years ago
MODERATORS
 

I have a nextcloud instance being hosted from my home network. The URL associated with it points directly at my home's IP. I don't want to host the instance on a VPS because disk space is expensive. So, instead, I want to point the URL at the VPS, and then somehow route the connection to my home's nextcloud instance without leaking my home's ip.

How might I go about doing this? Can this be achieved with nginx?

EDIT: Actually, not leaking my home's IP is not essential. It is acceptable if it is possible to determine the IP with some effort. What I really want is to be able to host multiple websites with my single home IP without those websites being obviously connected, and to avoid automatic bots constantly looking for vulnerabilities in my home network.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

After lots of testing I found a configuration that works for me! In the end it is very simple, but I am quite a newbie at this so it took some effort to figure out what works. ChatGPT helped a bit too - and also confused me a lot - but it helped.

What I do now is:

I set up a wireguard tunnel. The VPS in this example has the 'wireguard' ip of 10.222.0.1, and my home network is 10.222.0.2. These are my configs (/etc/wireguard/wg0.conf):

VPS wireguard config:

spoiler

[Interface]
Address = 10.222.0.1/24
ListenPort = 51820
PrivateKey = <VPS Private key>

[Peer]
PublicKey = <Home network public key>
AllowedIPs = 10.222.0.2/32
PersistentKeepalive = 25

Home network (Respberry pi) config :

spoiler

[Interface]
Address = 10.222.0.2/32
PrivateKey = <Home network private key>

[Peer]
PublicKey = <VPS Public Key>
Endpoint = <VPS_IP>:51820
AllowedIPs = 10.222.0.0/16
PersistentKeepalive = 25

Then, I use the following iptables commands in the VPS to map requests to port 80 and 443 to the ports 80 and 443 of the tunnel. What really confused me for a while was that I did not know that I needed to include the "POSTROUTING" step so that the packets get sent back the correct way, and that I had to set net.ipv4.ip_forward=1 in /etc/sysctl.conf:

IP tables in VPS:

spoiler


iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.222.0.2:443
iptables -t nat -A POSTROUTING -p tcp -d 10.222.0.2 --dport 443 -j SNAT --to-source 10.222.0.1
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.222.0.2:80
iptables -t nat -A POSTROUTING -p tcp -d 10.222.0.2 --dport 80 -j SNAT --to-source 10.222.0.1

Then, in my home network I use the standard nginx config:

spoiler

server {
  server_name website.com;
  listen 80;
  location / {
        return 301 https://$host$request_uri;
  }
}

server {
  server_name website.com;
    listen 443;
    location / {
        proxy_set_header Host $host;
        proxy_pass http://0.0.0.0:<Website Port>;
    }
    # certificate management here
    ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

This configuration seems to work, and since both ports 80 and 433 are mapped you can use certbot to generate and renew the SSL certificates automatically.

I am still learning, and this is the first thing that worked - so there might be a better way! But a lot of things I tried would not complete the SSL handshake correctly. > push m