💾 Archived View for gemini.stha.de › network captured on 2022-07-16 at 15:11:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
This page will give an overview about my completely over-engineered network configuration.
I add more content as soon as I find more time for it. :)
I rent two VPS where I run FreeBSD. Their names are "elysium.stha.de" and "deponia.stha.de". Both servers have one public IPv4 address and one public /64 IPv6 subnet each. Additionally I run FreeBSD on a Raspberry Pi 4 connected to my domestical Internet connection. The Pi is called "rufus.stha.de". While my cable connection should have a public /56 IPv6 prefix, the router of my ISP will only serve a /64 subnet. DHCPv6 prefix delegation was disabled with some firmware change.
All FreeBSD hosts are connected via fully meshed point-to-point Wireguard tunnels. Routing information is exchanged via the Babel dynamic routing protocol. Babel is handled by bird2 on all boxes.
Because point-to-point tunnels are somewhat broken for bird2 on FreeBSD I have to run a patched version of bird2. However, I plan to upstream my changes after improving the code quality a bit.
The FreeBSD hosts are only minimally configured. They only handle the networking stuff. All other software is installed in FreeBSD jails. There is a dedicated IPv6 subnet for all jails on each of the hosts.
The services running in the jails can talk to each other because routing information is exchanged dynamically via Babel. The FreeBSD hosts run a suitable PF firewall configuration.
This gemini capsule is hosted on my Raspberry Pi at home. Connection from outside of my home network are unfortunately not possible. Therefore two nginx instances on the two public VPSes are proxying the traffic over the Wireguard tunnel to my Pi.
Actually, this is the same for many other services, like Gitea and other things.
ns0.stha.de ldap.stha.de
mail.stha.de ns1.stha.de
mx0.stha.de mx1.stha.de
www0.stha.de www1.stha.de
+-----------------+ Wireguard +-----------------+
| elysium.stha.de |-----------| deponia.stha.de |
+-----------------+ +-----------------+
| | | |
| | | |
| | | |
| +------ I N T E R N E T ------+ |
| | |
| | |
| ########### Firewall |
| | |
| +---------------+ |
+-----------| rufus.stha.de |-------------+
Wireguard +---------------+ Wireguard
gemini.stha.de
git.stha.de
grocy.stha.de
radicale.stha.de
www2.stha.de
Mail is handled by two mail exchangers (MX), namely "mx0.stha.de" and "mx1.stha.de". Both mailers only accept mail for my domain. Currently they are running Postfix, but the latter might be replaced by opensmtpd. If one of the MXs receives mail for my domain, it will make a recipient address verification request against the server that actually hosts the mailboxes, "mail.stha.de". If the recipient address was succesfully verified, it is relayed to the mailbox server.
On the mailbox server opensmptd is handling all the SMTP traffic. It does alias expansion and delivers mail locally via a custom LDA script. The LDA script removes all header lines starting with "X-Spam" and scans the message with rspamd. After that the mail is piped through dovecot-lda so that the mail is finally delivered to the user. Locally submitted mail and authenticated SMTP sessions will have their message DKIM signed by dkimproxy. After that the signed mail is relayed to one of the MXs.
The zonefile for the root of the domain contains respective SPF and DMARC records:
stha.de. 3600 IN TXT "v=spf1 mx ~all" stha.de. 3600 IN MX 100 elysium.stha.de. stha.de. 3600 IN MX 100 deponia.stha.de. _dmarc.stha.de. 3600 IN TXT "v=DMARC1; p=none; sp=none" 20200509._domainkey.stha.de. 3600 IN TXT "k=rsa; p=[...]"
By the way, let's check if there are some scrapers active on the gemini network:
Last Update: 2021-09-09