New post: Self-host at home
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
This commit is contained in:
parent
6d9a033640
commit
0a908d134a
2 changed files with 220 additions and 0 deletions
|
|
@ -1,5 +1,123 @@
|
|||
#+hugo_base_dir: ../
|
||||
|
||||
* Comunidades difíceis :portugues:thoughts:rant:
|
||||
:PROPERTIES:
|
||||
:EXPORT_FILE_NAME: comunidades-dificeis
|
||||
:END:
|
||||
Uma constante em minha vida há muitos anos é o envolvimento com
|
||||
comunidades de Software Livre. É uma parte integral daquilo que me
|
||||
faz me sentir completo e feliz, e por isso eu não gosto de pensar que
|
||||
a possibilidade de poder dedicar meu tempo livre (e ocupado também!)
|
||||
pra tornar esse envolvimento concreto seja algo trivial. Pelo
|
||||
contrário: até hoje, mais de 15 anos depois da minha primeira
|
||||
contribuição pra um projeto Livre, eu ainda me pego agradecendo pelo
|
||||
privilégio de poder fazer daquilo que eu acredito algo que permeia
|
||||
minha vida. Mas é claro que nem tudo são flores.
|
||||
|
||||
"Comunidade" é só um nome bonito que a gente usa pra "um monte de
|
||||
pessoas juntas". E pessoas são complicadas, obviamente. Ainda mais
|
||||
aquelas que lidam com um ramo tão complexo, volátil e competitivo como
|
||||
o da computação. Por algum motivo, algumas comunidades agem como ímãs
|
||||
de pessoas mais complicadas, e ultimamente eu tenho pensado bastante
|
||||
nisso. Pra mim, é sempre um mistério entender o porquê de alguém
|
||||
perder seu tempo pra dificultar o trabalho de outros.
|
||||
|
||||
* DONE Using WireGuard to host services at home :english:howto:selfhost:wireguard:debian:
|
||||
CLOSED: [2023-05-23 Tue 00:56]
|
||||
:PROPERTIES:
|
||||
:EXPORT_FILE_NAME: using-wireguard-host-services-home
|
||||
:END:
|
||||
|
||||
It's been a while since I had this idea to leverage the power of
|
||||
[[https://wireguard.org][WireGuard]] to self-host stuff at home. Even though I pay for a proper
|
||||
server somewhere in the world, there are some services that I don't
|
||||
consider critical to put there, or that I consider *too* critical to
|
||||
host outside my home.
|
||||
|
||||
** It's only NATural
|
||||
|
||||
With today's ISP packages for end users, I find it very annoying the
|
||||
amount of trouble they create when you try to host anything at home.
|
||||
Dynamic IPs, NAT/CGNAT, port-blocking, traffic shapping are only a few
|
||||
examples of methods or limitations that prevent users from making
|
||||
local services reachable in a reliable way from outside.
|
||||
|
||||
** WireGuard comes to help
|
||||
|
||||
If you already pay for a VPS or a dedicated server somewhere, why not
|
||||
use its existing infrastructure (and public availability) in your
|
||||
favour? That's what I thought when I started this journey.
|
||||
|
||||
My initial idea was to use a reverse proxy to redirect external
|
||||
requests to the service running at my home. But how could I make sure
|
||||
that these requests reach my
|
||||
dynamic-IP-behind-a-NAT-behind-another-NAT? Well, let's create a
|
||||
tunnel! WireGuard is the perfect tool for that because of many
|
||||
things: it's stateless, very performant, secure, and requires very
|
||||
little configuration.
|
||||
|
||||
** Setting up on the server
|
||||
|
||||
On the server side (i.e., VPS or dedicated server), you will create
|
||||
the first endpoint. Something like the following should do:
|
||||
|
||||
#+begin_src
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.1/32
|
||||
ListenPort = 51821
|
||||
|
||||
[Peer]
|
||||
PublicKey = PUBLIC_KEY_HERE
|
||||
AllowedIps = 10.0.0.2/32
|
||||
PersistentKeepalive = 10
|
||||
#+end_src
|
||||
|
||||
A few interesting points to note:
|
||||
|
||||
- The =Peer= section contains information about the home service that
|
||||
will be configured below.
|
||||
- I'm using =PersistentKeepalive= because I have a dynamic IP at my
|
||||
home. If you have a static IP, you could get rid of
|
||||
=PersistentKeepalive= and specify an =Endpoint= here (don't forget
|
||||
to set a =ListenPort= *below*, in the =Interface= section).
|
||||
- Now you have an IP where you can forward requests to. If we're
|
||||
talking about HTTP traffic, Apache and nginx are absolutely capable
|
||||
of doing it. If we're talking about other kind of traffic, you
|
||||
might want to look into other utilities, like [[https://www.haproxy.org/][HAProxy]], [[https://traefik.io/traefik/][Traefik]] and
|
||||
others.
|
||||
|
||||
** Setting up at your home
|
||||
|
||||
At your home, you will configure the peer:
|
||||
|
||||
#+begin_src
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.2/32
|
||||
|
||||
[Peer]
|
||||
PublicKey = PUBLIC_KEY_HERE
|
||||
AllowedIps = 10.0.0.1/32
|
||||
Endpoint = YOUR_SERVER:51821
|
||||
PersistentKeepalive = 10
|
||||
#+end_src
|
||||
|
||||
** A few notes about security
|
||||
|
||||
I would be remiss if I didn't say anything about security, especially
|
||||
because we're talking about hosting services at home. So, here are a
|
||||
few recommendations:
|
||||
|
||||
- Make sure to put your services in a separate local network. Using
|
||||
VLANs is also a good option.
|
||||
- Don't run services on your personal (or work!) computer, even if
|
||||
they'll be running inside a VM.
|
||||
- Run a firewall on the WireGuard interface and make sure that you
|
||||
only allow traffic over the required ports.
|
||||
|
||||
Have fun!
|
||||
|
||||
* DONE Ubuntu debuginfod and source code indexing :english:ubuntu:debuginfod:debian:free_software:gdb:
|
||||
CLOSED: [2023-05-13 Sat 16:43]
|
||||
:PROPERTIES:
|
||||
|
|
|
|||
102
content/posts/using-wireguard-host-services-home.md
Normal file
102
content/posts/using-wireguard-host-services-home.md
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
+++
|
||||
title = "Using WireGuard to host services at home"
|
||||
author = ["Sergio Durigan Junior"]
|
||||
date = 2023-05-23T00:56:00-04:00
|
||||
tags = ["english", "howto", "selfhost", "wireguard", "debian"]
|
||||
draft = false
|
||||
+++
|
||||
|
||||
It's been a while since I had this idea to leverage the power of
|
||||
[WireGuard](https://wireguard.org) to self-host stuff at home. Even though I pay for a proper
|
||||
server somewhere in the world, there are some services that I don't
|
||||
consider critical to put there, or that I consider **too** critical to
|
||||
host outside my home.
|
||||
|
||||
|
||||
## It's only NATural {#it-s-only-natural}
|
||||
|
||||
With today's ISP packages for end users, I find it very annoying the
|
||||
amount of trouble they create when you try to host anything at home.
|
||||
Dynamic IPs, NAT/CGNAT, port-blocking, traffic shapping are only a few
|
||||
examples of methods or limitations that prevent users from making
|
||||
local services reachable in a reliable way from outside.
|
||||
|
||||
|
||||
## WireGuard comes to help {#wireguard-comes-to-help}
|
||||
|
||||
If you already pay for a VPS or a dedicated server somewhere, why not
|
||||
use its existing infrastructure (and public availability) in your
|
||||
favour? That's what I thought when I started this journey.
|
||||
|
||||
My initial idea was to use a reverse proxy to redirect external
|
||||
requests to the service running at my home. But how could I make sure
|
||||
that these requests reach my
|
||||
dynamic-IP-behind-a-NAT-behind-another-NAT? Well, let's create a
|
||||
tunnel! WireGuard is the perfect tool for that because of many
|
||||
things: it's stateless, very performant, secure, and requires very
|
||||
little configuration.
|
||||
|
||||
|
||||
## Setting up on the server {#setting-up-on-the-server}
|
||||
|
||||
On the server side (i.e., VPS or dedicated server), you will create
|
||||
the first endpoint. Something like the following should do:
|
||||
|
||||
```nil
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.1/32
|
||||
ListenPort = 51821
|
||||
|
||||
[Peer]
|
||||
PublicKey = PUBLIC_KEY_HERE
|
||||
AllowedIps = 10.0.0.2/32
|
||||
PersistentKeepalive = 10
|
||||
```
|
||||
|
||||
A few interesting points to note:
|
||||
|
||||
- The `Peer` section contains information about the home service that
|
||||
will be configured below.
|
||||
- I'm using `PersistentKeepalive` because I have a dynamic IP at my
|
||||
home. If you have a static IP, you could get rid of
|
||||
`PersistentKeepalive` and specify an `Endpoint` here (don't forget
|
||||
to set a `ListenPort` **below**, in the `Interface` section).
|
||||
- Now you have an IP where you can forward requests to. If we're
|
||||
talking about HTTP traffic, Apache and nginx are absolutely capable
|
||||
of doing it. If we're talking about other kind of traffic, you
|
||||
might want to look into other utilities, like [HAProxy](https://www.haproxy.org/), [Traefik](https://traefik.io/traefik/) and
|
||||
others.
|
||||
|
||||
|
||||
## Setting up at your home {#setting-up-at-your-home}
|
||||
|
||||
At your home, you will configure the peer:
|
||||
|
||||
```nil
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.2/32
|
||||
|
||||
[Peer]
|
||||
PublicKey = PUBLIC_KEY_HERE
|
||||
AllowedIps = 10.0.0.1/32
|
||||
Endpoint = YOUR_SERVER:51821
|
||||
PersistentKeepalive = 10
|
||||
```
|
||||
|
||||
|
||||
## A few notes about security {#a-few-notes-about-security}
|
||||
|
||||
I would be remiss if I didn't say anything about security, especially
|
||||
because we're talking about hosting services at home. So, here are a
|
||||
few recommendations:
|
||||
|
||||
- Make sure to put your services in a separate local network. Using
|
||||
VLANs is also a good option.
|
||||
- Don't run services on your personal (or work!) computer, even if
|
||||
they'll be running inside a VM.
|
||||
- Run a firewall on the WireGuard interface and make sure that you
|
||||
only allow traffic over the required ports.
|
||||
|
||||
Have fun!
|
||||
Loading…
Reference in a new issue