- architectuur: - IPv6
Client–Server Architectuur (huidige setup versie 6)
0. Doel en scope
Dit document beschrijft de huidige client–server opzet zoals die nu in productie en beheer wordt gebruikt. Het doel is: - reproduceerbaarheid van de setup - eenvoudiger troubleshooting - gecontroleerde uitbreiding zonder security-regressies
De focus ligt op: - publieke toegang via nginx reverse proxy - privé beheer via WireGuard VPN - strikte firewalling met nftables (default drop)
1. Clients
1.1 macOS
- Browser (Safari) voor publieke webtoegang
- SSH, rsync, scp, sshfs voor beheer
- WireGuard client voor privé toegang
1.2 iPhone
- Alleen browser (HTTPS)
- Geen VPN vereist voor publieke applicaties
- Alle services bereikbaar via nginx (poort 443)
2. Server (publiek)
2.1 Algemene kenmerken
- OS: Ubuntu (VPS)
- Publiek IP: 89.167.39.46
- DNS: www.public-risk.org → A-record naar dit IP
2.2 Draaiende kernservices
- nginx (reverse proxy, TLS terminatie)
- shiny-server (lokaal bereikbaar)
- wireguard (wg0)
- nftables (firewall)
3. Netwerkmodel
3.1 Publiek vlak
- Toegang via HTTPS (poort 443)
- nginx bepaalt welke applicaties publiek zichtbaar zijn
- Eindgebruikers hebben geen directe toegang tot interne poorten
3.2 Privé vlak (VPN)
- WireGuard subnet: 10.8.0.0/24
- Beheer vanaf macOS clients
- Toegang tot:
- SSH
- interne services
- Raspberry Pi nodes
4. Poorten en bereik
4.1 Publiek toegankelijk
| Poort | Protocol | Functie |
|---|---|---|
| 80 | TCP | HTTP (redirect naar HTTPS) |
| 443 | TCP | HTTPS via nginx |
| 51820 | UDP | WireGuard |
4.2 Niet publiek
| Poort | Protocol | Bereik |
|---|---|---|
| 3838 | TCP | lokaal / VPN (Shiny Server) |
| 22 | TCP | VPN / whitelist |
| overig | TCP/UDP | tijdelijk via dynamic_ports |
5. Reverse proxy (nginx)
5.1 Rol
- Centrale toegangspoort voor alle publieke services
- TLS terminatie
- Path-based routing naar backend services
5.2 Shiny
- Shiny Server luistert niet publiek
- Publieke toegang verloopt via nginx
- Applicaties zijn bereikbaar via een URL-prefix
(bijvoorbeeld
/pi/<app>/)
Gevolg:
- geen directe toegang tot :3838 nodig
- consistente URL’s voor desktop en mobiel
- extra beveiliging en controle op één plek
6. Firewall model (nftables)
6.1 Basisprincipe
- Default policy: drop
- Alleen expliciet toegestane traffic wordt geaccepteerd
6.2 Toegestane categorieën
- established, related
- loopback + ICMP
- WireGuard verkeer (UDP 51820)
- VPN subnet (10.8.0.0/24)
- whitelists (bijv. SSH)
- dynamische poorten via aparte chain
- blacklist heeft altijd prioriteit (hard drop)
7. Raspberry Pi nodes
- Niet publiek bereikbaar
- Beheer uitsluitend via VPN
- Leveren data en diensten aan:
- de VPS
- of rechtstreeks aan clients via de VPS (proxy)
8. Bestandsbeheer vanaf macOS
8.1 Finder via sftp
- Technisch mogelijk
- In de praktijk onbetrouwbaar door LaunchServices-associaties
8.2 SSHFS (aanbevolen)
- Mount remote directories als lokaal bestandssysteem
- Geschikt voor actief beheer en ontwikkeling
Voorbeeld: sshfs pi@10.8.0.1:/home/pi ~/mnt/public-risk \ -o reconnect \ -o ServerAliveInterval=15 \ -o ServerAliveCountMax=3 \ -o defer_permissions \ -o noappledouble \ -o noapplexattr
9. Operationele checks
9.1 Webtoegang
- lokaal:
curl -I http://localhost/pi/
/ - extern:
curl -I https://www.public-risk.org/pi/
/
9.2 Shiny binding
ss -ltnp | grep 3838
Verwacht: alleen localhost of VPN-interface
9.3 VPN status
sudo wg show
9.4 Firewall
sudo nft list ruleset
10. Uitgangspunten voor uitbreiding
- Nieuwe publieke services altijd via nginx
- Geen directe poort-exposure zonder expliciete reden
- Beheer blijft via VPN
- Documentatie bijwerken vóór live-gang