bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructured Documentation
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 8s
Details

Browse Source
This commit is contained in:
Nicole Rappe
2026-09-05 14:08:43 -06:00
parent c4bd235eba
commit 289769a601
281 changed files with 5403 additions and 3563 deletions
Download Patch File Download Diff File Expand all files Collapse all files
deployments/Networking and Access/DNS/AdGuard Home.md
+38
View File
@@ -0,0 +1,38 @@
---
tags:
- AdGuard Home
- DNS
- Docker
---
## Purpose
AdGuard Home is a network-wide software for blocking ads & tracking. After you set it up, it will cover ALL your home devices, and you don’t need any client-side software for that. With the rise of Internet-Of-Things and connected devices, it becomes more and more important to be able to control your whole network.
```yaml title="docker-compose.yml"
version: '3'
services:
app:
image: adguard/adguardhome
ports:
- 3000:3000
- 53:53
- 80:80
volumes:
- /srv/containers/adguard_home/workingdir:/opt/adguardhome/work
- /srv/containers/adguard_home/config:/opt/adguardhome/conf
restart: always
networks:
docker_network:
ipv4_address: 192.168.5.189
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/DNS/Pi Hole.md
+53
View File
@@ -0,0 +1,53 @@
---
tags:
- Pi-hole
- DNS
- Docker
---
## Purpose
Pi-hole is a Linux network-level advertisement and Internet tracker blocking application which acts as a DNS sinkhole and optionally a DHCP server, intended for use on a private network.
```yaml title="docker-compose.yml"
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
- "80:80/tcp"
environment:
TZ: 'America/Denver'
WEBPASSWORD: 'REDACTED' #USE A SECURE PASSWORD HERE
# Volumes store your data between container upgrades
volumes:
- /srv/containers/pihole/app:/etc/pihole
- /srv/containers/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
restart: always
networks:
docker_network:
ipv4_address: 192.168.5.190
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
```yaml title=".env"
Not Applicable
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/NetBird/Deploy NetBird on Rocky Linux.md
+55
View File
@@ -0,0 +1,55 @@
---
tags:
- NetBird
- VPN
- Networking
- Docker
---
## Purpose
Netbird is a free and open-source VPN server and client platform. The following document will illustrate how to deploy Netbird into a homelab or business environment.
!!! note "Assumptions"
It is assumed that you are running Rocky Linux 10. You can technically use anything, but the command syntax will be different depending on the platform, and this document will not outline every possible operating system.
### Install Prerequisites
You need to install a few things before we can begin with the deployment of Netbird. Run the following commands set up the server environment before Netbird deployment. This also assumes that you opened all of the necessary ports listed in the [official Netbird deployment documentation](https://docs.netbird.io/selfhosted/selfhosted-quickstart) as well as set up a reverse proxy pointing to port 80 on the Netbird server.
!!! warning "Run as Non-Sudo"
Run all of the commands below as a normal user, do not use `sudo su` when deploying Netbird.
```sh
# Update system & install necessary packages
sudo dnf update -y
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin jq
sudo systemctl enable docker --now
# Configure normal user to have docker privileges
sudo usermod -aG docker nicole
# Logout and log back in via SSH
exit
ssh nicole@192.168.3.65
# Create Netbird project directory and pull down installation files
sudo mkdir -p /srv/containers/netbird
sudo chmod -R 770 /srv/containers/netbird
sudo chown -R nicole:docker /srv/containers/netbird
cd /srv/containers/netbird
curl -sSLO https://github.com/netbirdio/netbird/releases/latest/download/getting-started-with-zitadel.sh
# Deploy Netbird
export NETBIRD_DOMAIN=vpn.bunny-lab.io
bash getting-started-with-zitadel.sh
```
### Example Deployment Output
If everything is working correctly, you can go make some coffee and come back. When everything is done getting set up, you will see output similar to the below:
```sh
```
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Remote Access/Apache Guacamole.md
+160
View File
@@ -0,0 +1,160 @@
---
tags:
- Apache Guacamole
- Docker
---
## Purpose
HTML5-based Remote Access Broker for SSH, RDP, and VNC. Useful for remote access into an environment.
### Docker Compose Stack
=== "docker-compose.yml"
```yaml
version: '3'
services:
app:
image: jasonbean/guacamole
ports:
- 8080:8080
volumes:
- /srv/containers/guacamole:/config
environment:
- OPT_MYSQL=Y
- OPT_MYSQL_EXTENSION=N
- OPT_SQLSERVER=N
- OPT_LDAP=N
- OPT_DUO=N
- OPT_CAS=N
- OPT_TOTP=Y # (1)
- OPT_QUICKCONNECT=N
- OPT_HEADER=N
- OPT_SAML=N
- PUID=99
- PGID=100
- TZ=America/Denver # (2)
restart: unless-stopped
networks:
docker_network:
ipv4_address: 192.168.5.43
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
1. Enable this if you want multi-factor authentication enabled. Must be set BEFORE the container is initially deployed. Cannot be added retroactively.
2. Set to your own timezone.
=== "docker-compose.yml (OpenID / Keycloak Integration)"
```yaml
version: '3'
services:
app:
image: jasonbean/guacamole
ports:
- 8080:8080
volumes:
- /srv/containers/apache-guacamole:/config
environment:
- OPT_MYSQL=Y
- OPT_MYSQL_EXTENSION=N
- OPT_SQLSERVER=N
- OPT_LDAP=N
- OPT_DUO=N
- OPT_CAS=N
- OPT_TOTP=N
- OPT_QUICKCONNECT=N
- OPT_HEADER=N
- OPT_SAML=N
- OPT_OIDC=Y # Enable OpenID Connect
- OIDC_ISSUER=${OPENID_REALM_URL} # Your Keycloak realm URL
- OIDC_CLIENT_ID=${OPENID_CLIENT_ID} # Client ID for Guacamole in Keycloak
- OIDC_CLIENT_SECRET=${OPENID_CLIENT_SECRET} # Client Secret for Guacamole in Keycloak
- OIDC_REDIRECT_URI=${OPENID_REDIRECT_URI} # Redirect URI for Guacamole
- PUID=99
- PGID=100
- TZ=America/Denver
restart: unless-stopped
networks:
docker_network:
ipv4_address: 192.168.5.43
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
1. You cannot enable TOTP / Multi-factor authentication if you have OpenID configured. This is just a known issue.
2. Set to your own timezone.
### Environment Variables
=== ".env"
```sh
N/A
```
=== ".env (OpenID / Keycloak Integration)"
```yaml
OPENID_REALM_URL=https://auth.bunny-lab.io/realms/master
OPENID_CLIENT_ID=apache-guacamole
OPENID_CLIENT_SECRET=<YOUR-CLIENT-ID-SECRET>
OPENID_REDIRECT_URI=http://remote.bunny-lab.io
```
## Reverse Proxy Configuration
=== "Traefik"
```yaml
http:
routers:
apache-guacamole:
entryPoints:
- websecure
tls:
certResolver: letsencrypt
service: apache-guacamole
rule: Host(`remote.bunny-lab.io`)
services:
apache-guacamole:
loadBalancer:
servers:
- url: http://192.168.5.43:8080
passHostHeader: true
```
=== "NGINX"
```yaml
server {
listen 443 ssl;
server_name remote.bunny-lab.io;
client_max_body_size 0;
ssl on;
location / {
proxy_pass http://192.168.5.43:8080;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
access_log off;
}
}
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Remote Access/Firefox.md
+115
View File
@@ -0,0 +1,115 @@
---
tags:
- Firefox
- Docker
---
## Purpose
Sometimes you just want an instance of Firefox running on an Alpine Linux container, that has persistence (Extensions, bookmarks, history, etc) outside of the container (with bind-mapped folders). This is useful for a number of reasons, but insecure by default, so you have to protect it behind something like a [Keycloak Server](<../../Identity and Certificates/Keycloak/Deploy Keycloak.md>) so it is not misused.
## Keycloak Authentication Sequence
```mermaid
sequenceDiagram
participant User
participant Traefik as Traefik Reverse Proxy
participant Keycloak
participant RockyLinux as Rocky Linux VM
participant FirewallD as FirewallD
participant Alpine as Alpine Container
User->>Traefik: Access https://work-environment.bunny-lab.io
Traefik->>Keycloak: Redirect to Authenticate against Work Realm
User->>Keycloak: Authenticate
Keycloak->>User: Authorization Cookie Stored on Internet Browser
User->>Traefik: Pass Authorization Cookie to Traefik
Traefik->>RockyLinux: Traefik Forwards Traffic to Rocky Linux VM
RockyLinux->>FirewallD: Traffic Passes Local Firewall
FirewallD->>RockyLinux: Filter traffic (Port 5800)
FirewallD->>Alpine: Allow Traffic from Traefik
Alpine->>User: WebUI Access to Firefox Work Environment Granted
```
## Docker Configuration
```yaml title="docker-compose.yml"
version: '3'
services:
firefox:
image: jlesage/firefox # Docker image for Firefox
environment:
- TZ=America/Denver # Timezone setting
- DARK_MODE=1 # Enable dark mode
- WEB_AUDIO=1 # Enable web audio
- KEEP_APP_RUNNING=1 # Keep the application running
ports:
- "5800:5800" # Port mapping for VNC WebUI
volumes:
- /srv/containers/firefox:/config:rw # Persistent storage for configuration
restart: always # Always restart the container in case of failure
network_mode: host # Use the host network
```
```yaml title=".env"
N/A
```
## Local Firewall Hardening
It is important, due to how this browser just allows anyone to access it, to lock it down to only allow access to the SSH port and port 5800 to specifically-allowed devices, in this case, the Traefik Reverse Proxy. This ensures that it only allows the proxy to communicate with Firefox's container, keeping it securely protected behind Keycloak's middware in Traefik.
These rules will drop all traffic by default, allow port 22, and restrict access to port 5800.
```sh
# Set the default zone to drop
sudo firewall-cmd --set-default-zone=drop
# Create a new zone named custom-trusted
sudo firewall-cmd --permanent --new-zone=traefik-proxy
# Allow traffic to port 5800 only from 192.168.5.29 in the traefik-proxy zone
sudo firewall-cmd --permanent --zone=traefik-proxy --add-source=192.168.5.29
sudo firewall-cmd --permanent --zone=traefik-proxy --add-port=5800/tcp
# Allow SSH traffic on port 22 from any IP in the drop zone
sudo firewall-cmd --permanent --zone=drop --add-service=ssh
# Reload FirewallD to apply the changes
sudo firewall-cmd --reload
```
## Traefik Reverse Proxy Configuration
If the container does not run on the same host as Traefik, you will need to manually add configuration to Traefik's dynamic config file, outlined below.
```yaml
http:
routers:
work-environment:
entryPoints:
- websecure
tls:
certResolver: letsencrypt
service: work-environment
rule: Host(`work-environment.bunny-lab.io`)
middlewares:
- work-environment # Referencing the Keycloak Server
services:
work-environment:
loadBalancer:
servers:
- url: http://192.168.5.4:5800
passHostHeader: true
# # Adding forwardingTimeouts to set the send and read timeouts to 1 hour (3600 seconds)
# forwardingTimeouts:
# dialTimeout: "3600s"
# responseHeaderTimeout: "3600s"
```
## Firefox Special Configurations
Due to the nature of how this is deployed, you need to make some additional configurations to the Firefox settings after-the-fact. Some of this could be automated with environment variables at deployment time, but for now will be handled manually.
- **Install Power Tabs Extension**: This extension is useful for keeping things organized.
- **Install Merge All Windows Extension**: At times, you may misclick somewhere in the Firefox environment causing Firefox to open a new instance / window losing all of your tabs, and because there is no window manager, there is no way to alt+tab or switch between the instances of Firefox, effectively breaking your current session forcing you to re-open tabs. With this extension, you can merge all of the windows, collapsing them into one window, resolving the issue.
- **Configure New Tab behavior**: If a new tab opens in a new window, it will absolutely throw everything into disarray, that is why all hyperlinks will be forced to open in a new tab instead of a new window. You can do this by navigating to `about:config` and setting the variable `browser.link.open_newwindow.restriction` to a value of `0`. [Original Reference Documentation](https://support.mozilla.org/en-US/questions/1066799)
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
- [Traefik Deployment](<../Reverse Proxies/Traefik.md>) — Prepare the reverse proxy before applying this page's routing configuration.
deployments/Networking and Access/Remote Access/Install XFCE and RustDesk on Fedora Server.md
+83
View File
@@ -0,0 +1,83 @@
---
tags:
- Fedora
- Linux
- Desktop Environment
- Workstation
---
## Purpose
You may find that you need to install an XFCE desktop environment or something into Fedora Server, if this is the case, for installing something like Rustdesk remote access, you can follow the steps below.
### Install and Configure XFCE
We need to install XFCE and configure it to be the default environment when the server turns on.
```sh
sudo dnf install @xfce-desktop-environment -y
sudo systemctl set-default graphical.target
sudo reboot
```
#### Install Rustdesk
We need to install Rustdesk into the server.
```sh
curl -L -o /tmp/rustdesk_installer.rpm https://github.com/rustdesk/rustdesk/releases/download/1.4.0/rustdesk-1.4.0-0.x86_64.rpm
cd /tmp
sudo yum install rustdesk_installer.rpm -y
```
!!! info "Configure Rustdesk"
You need to use a tool like "MobaXTerm" or "PuTTy" to leverage X11-Forwarding to allow you to run `rustdesk` in a GUI on your local workstation. From there, you need to configure the relay server information (if you are using a self-hosted Relay). This is also where you would set up a permanent password to the server and document the device ID number.
Be sure to check the box for "**Enable remote configuration modification**" when setting up Rustdesk.
### Configure Automatic Login
For Rustdesk specifically, we have to configure XFCE to automatically login via SDDM then immediately lock the computer once it's logged in, so the XFCE session is running, allowing Rustdesk to connect to it.
**Create SDDM Config File**:
```sh
sudo mkdir -p /etc/sddm.conf.d/
sudo nano /etc/sddm.conf.d/autologin.conf
```
```ini title="/etc/sddm.conf.d/autologin.conf"
[Autologin]
User=nicole
Session=xfce.desktop
```
!!! note "Determining Session Strings"
If you're unsure of the correct session string, check what's available by typing `ls /usr/share/xsessions/`. You will be looking for something like `xfce.desktop`
### Configure Lock on Initial Login
At this point, its not the most secure thing to just leave a server logged-in upon boot, so the following steps will instantly lock the server after logging in, allowing the XFCE session to persist so Rustdesk can attach to it for remote management of the server.
!!! warning "Not Functional Yet"
I have tried implementing the below, but it seems to just ignore it and stay logged-in without locking the device. This needs to be troubleshot further.
```sh
mkdir -p ~/.config/autostart
nano ~/.config/autostart/xfce-lock.desktop
```
```ini title="~/.config/autostart/xfce-lock.desktop"
[Desktop Entry]
Type=Application
Exec=xfce4-screensaver-command -l
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Auto Lock
Comment=Lock the screen on login
```
Lastly, test that everything is working by rebooting the server.
```sh
sudo reboot
```
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Remote Access/Install XRDP on Ubuntu.md
+29
View File
@@ -0,0 +1,29 @@
---
tags:
- XRDP
- Bash
- Scripting
- Linux
---
## Purpose
If you need to set up RDP access to a Linux environment, you will want to install XRDP. Once it is installed, you can leverage other tools such as Apache Guacamole to remotely connect to it.
```sh
# Install and Start XRDP Service
sudo dnf install epel-release -y
sudo dnf install xrdp -y
sudo systemctl enable --now xrdp
# Open Firewall Rules for RDP Traffic
sudo firewall-cmd --permanent --add-port=3389/tcp
sudo firewall-cmd --reload
# Configure Desktop Environment to Launch when you Login via RDP (Run as Non-Root User)
# XFCE4 Desktop Environment
echo "startxfce4" > ~/.Xclients
chmod +x ~/.Xclients
```
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Reverse Proxies/Nginx.md
+46
View File
@@ -0,0 +1,46 @@
---
tags:
- Nginx
- Reverse Proxy
- Docker
---
## Purpose
NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more.
```yaml title="docker-compose.yml"
---
version: "2.1"
services:
nginx:
image: lscr.io/linuxserver/nginx:latest
container_name: nginx
environment:
- PUID=1000
- PGID=1000
- TZ=America/Denver
volumes:
- /srv/containers/nginx-portfolio-website:/config
ports:
- 80:80
- 443:443
restart: unless-stopped
networks:
docker_network:
ipv4_address: 192.168.5.12
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
```yaml title=".env"
Not Applicable
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Reverse Proxies/Traefik.md
+203
View File
@@ -0,0 +1,203 @@
---
tags:
- Traefik
- Reverse Proxy
- Docker
---
## Purpose
A traefik reverse proxy is a server that sits between your network firewall and servers hosting various web services on your private network(s). Traefik automatically handles the creation of Let's Encrypt SSL certificates if you have a domain registrar that is supported by Traefik such as CloudFlare; by leveraging API keys, Traefik can automatically make the DNS records for Let's Encrypt's DNS "challenges" whenever you add a service behind the Traefik reverse proxy.
!!! info "Assumptions"
This Traefik deployment document assumes you have deployed [Portainer](<../../Containers/Docker/Deploy Portainer.md>) to either a Rocky Linux or Ubuntu Server environment. Other docker-compose friendly operating systems have not been tested, so your mileage may vary regarding successful deployment ouside of these two operating systems.
Portainer makes deploying and updating Traefik so much easier than via a CLI. It's also much more intuitive.
## Deployment on Portainer
- Login to Portainer (e.g. https://<portainer-ip>:9443)
- Navigate to "**Environment (usually "local") > Stacks > "+ Add Stack"**"
- Enter the following `docker-compose.yml` and `.env` environment variables into the webpage
- When you have finished making adjustments to the environment variables (and docker-compose data if needed), click the "**Deploy the Stack**" button
!!! warning "Get DNS Registrar API Keys BEFORE DEPLOYMENT"
When you are deploying this container, you have to be mindful to set valid data for the environment variables related to the DNS registrar. In this example, it is CloudFlare.
```text title="Environment Variables"
CF_API_EMAIL=nicole.rappe@bunny-lab.io
CF_API_KEY=REDACTED-CLOUDFLARE-DOMAIN-API-KEY
```
If these are not set, Traefik will still work, but SSL certificates will not be issued from Let's Encrypt, and SSL traffic will be terminated using a self-signed Traefik-based certificate, which is only good for local non-production testing.
If you plan on using HTTP-based challenges, you will need to make the following changes in the docker-compose.yml data:
- Un-comment `"--certificatesresolvers.myresolver.acme.tlschallenge=true"`
- Comment-out `"--certificatesresolvers.letsencrypt.acme.dnschallenge=true"`
- Comment-out `"--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare"`
- Lastly, you need to ensure that port 80 on your firewall is opened to the IP of the Traefik Reverse Proxy to allow Let's Encrypt to do TLS-based challenges.
### Stack Deployment Information
```yaml title="docker-compose.yml"
version: "3.3"
services:
traefik:
image: "traefik:latest"
restart: always
container_name: "traefik-bunny-lab-io"
cap_add:
- NET_ADMIN
entrypoint:
- /bin/sh
- -lc
- |
ip link set dev eth0 mtu 1500
exec traefik "$@"
ulimits:
nofile:
soft: 65536
hard: 65536
labels:
- "traefik.http.routers.traefik-proxy.middlewares=my-buffering"
- "traefik.http.middlewares.my-buffering.buffering.maxRequestBodyBytes=104857600"
- "traefik.http.middlewares.my-buffering.buffering.maxResponseBodyBytes=104857600"
- "traefik.http.middlewares.my-buffering.buffering.memRequestBodyBytes=2097152"
- "traefik.http.middlewares.my-buffering.buffering.memResponseBodyBytes=2097152"
- "traefik.http.middlewares.my-buffering.buffering.retryExpression=IsNetworkError() && Attempts() <= 2"
command:
# Globals
- "--log.level=ERROR"
- "--api.insecure=true"
- "--global.sendAnonymousUsage=false"
# Docker
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
# File Provider
- "--providers.file.directory=/etc/traefik/dynamic"
- "--providers.file.watch=true"
# Entrypoints
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--entrypoints.web.http.redirections.entrypoint.to=websecure" # Redirect HTTP to HTTPS
- "--entrypoints.web.http.redirections.entrypoint.scheme=https" # Redirect HTTP to HTTPS
- "--entrypoints.web.http.redirections.entrypoint.permanent=true" # Redirect HTTP to HTTPS
# LetsEncrypt
### - "--certificatesresolvers.myresolver.acme.tlschallenge=true" # Enable if doing Port 80 Let's Encrypt Challenges
- "--certificatesresolvers.letsencrypt.acme.dnschallenge=true" # Disable if doing Port 80 Let's Encrypt Challenges
- "--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare" # Disable if doing Port 80 Let's Encrypt Challenges
- "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
- "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
# Keycloak plugin configuration
- "--experimental.plugins.keycloakopenid.moduleName=github.com/Gwojda/keycloakopenid" # Optional if you have Keycloak Deployed
- "--experimental.plugins.keycloakopenid.version=v0.1.34" # Optional if you have Keycloak Deployed
ports:
- "80:80"
- "443:443"
- "8080:8080"
volumes:
- "/srv/containers/traefik/letsencrypt:/letsencrypt"
- "/srv/containers/traefik/config:/etc/traefik"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "/srv/containers/traefik/cloudflare:/cloudflare"
networks:
docker_network:
ipv4_address: 192.168.5.29
environment:
- CF_API_EMAIL=${CF_API_EMAIL}
- CF_API_KEY=${CF_API_KEY}
extra_hosts:
- "mail.bunny-lab.io:192.168.3.13" # Just an Example
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
```yaml title=".env"
CF_API_EMAIL=nicole.rappe@bunny-lab.io
CF_API_KEY=REDACTED-CLOUDFLARE-DOMAIN-API-KEY
LETSENCRYPT_EMAIL=nicole.rappe@bunny-lab.io
```
!!! info
There is a distinction between the "Global API Key" and a "Token API Key". The main difference being that the "Global API Key" can change anything in Cloudflare, while the "Token API Key" can only change what it was granted delegated permissions to.
## Adding Servers / Services to Traefik
Traefik operates in two ways, the first is labels, while the second are dynamic configuration files. We will go over each below.
### Docker-Compose Labels
The first is that it reads "labels" from the docker-compose file of any deployed containers on the same host as Traefik. These labels typically look something like the following:
```yaml title="docker-compose.yml"
labels:
- "traefik.enable=true"
- "traefik.http.routers.gitea.rule=Host(`example.bunny-lab.io`)"
- "traefik.http.routers.gitea.entrypoints=websecure"
- "traefik.http.routers.gitea.tls.certresolver=letsencrypt"
- "traefik.http.services.gitea.loadbalancer.server.port=8080"
```
By adding these labels to any container on the same server as Traefik, traefik will automatically "adopt" this service and route traffic to it as well as assign an SSL certificate to it from Let's Encrypt. The only downside is as mentioned above, if you are dealing with something that is not just a container, or maybe a container on a different physical server, you need to rely on dynamic configuration files, such as the one seen below.
### Dynamic Configuration Files
Dynamic configuration files exist under the Traefik container located at `/etc/traefik/dynamic`. Any `*.yml` files located in this folder will be hot-loaded anytime they are modified. This makes it convenient to leverage something such as the [Git Repo Updater](<../../Containers/Docker/Git Repo Updater.md>) container to leverage [Gitea](<../../automation/Gitea/Gitea.md>) to push configuration files from Git into the production environment, saving yourself headache and enabling version control over every service behind the reverse proxy.
An example of a dynamic configuration file would look something like this:
```yaml title="/etc/traefik/dynamic/example.bunny-lab.io.yml"
http:
routers:
example:
entryPoints:
- websecure
tls:
certResolver: letsencrypt
http2:
service: example
rule: Host(`example.bunny-lab.io`)
services:
example:
loadBalancer:
servers:
- url: http://192.168.5.70:8080
passHostHeader: true
```
You can see the similarities between the labeling method and how you designate the proxy name `example.bunny-lab.io` the internal ip address `192.168.5.70` the protocol to request the data from the service internally `http`, and the port the server is listening on internally `8080`. If you want to know more about the parameters such as `passHostHeader: true` then you will need to do some of your own research into it.
!!! example "Service Naming Considerations"
When you deploy a service into a Traefik-based reverse proxy, the name of the `router` and `service` have to be unique. The router can have the same name as the service, such as `example`, but I recommend naming the services to match the FQDN of the service itself.
For example, `remote.bunny-lab.io` would be written as `remote-bunny-lab-io`. This keeps things organized and easy to read if you are troubleshooting things in Traefik's logs or webUI. The complete configuration file would look like the example below:
```yaml title="/etc/traefik/dynamic/remote.bunny-lab.io.yml"
http:
routers:
remote-bunny-lab-io:
entryPoints:
- websecure
tls:
certResolver: letsencrypt
http2:
service: remote-bunny-lab-io
rule: Host(`remote.bunny-lab.io`)
services:
remote-bunny-lab-io:
loadBalancer:
servers:
- url: http://192.168.5.70:8080
passHostHeader: true
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Gitea Configuration Delivery](<../../../reference/Automation/Gitea Configuration Delivery.md>) — Choose the delivery implementation for the dynamic configuration directory.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/Sophos/Configure a Site-to-Site IPsec VPN.md
+104
View File
@@ -0,0 +1,104 @@
---
tags:
- Sophos
- IPsec
- VPN
- Firewall
- Routing
---
## Purpose
You may have two Sophos XGS appliances (or a mixed configuration) and need to set up a site-to-site VPN tunnel between two remote locations. You can achieve this with a simple passphrase-based IPSec VPN tunnel.
!!! info "Assumptions"
This documentation only provides instruction for Sophos XGS based devices. It does not account for third-party vendors or other manufactured hardware. If you need to set up a mixed VPN tunnel with a different brand of networking device, you need to do your best to match the settings on the tunnels manually. (e.g. Encryption Type, Phase Lifetimes, etc).
## Architecture
!!! tip "Best Practices - Initiators / Responders"
If you have a hub-and-spoke network, where one location acts as a central authority (e.g. domain controllers, auth servers, identity providers, headquarters, etc), you will set up the central "hub" as a VPN responder on its side of the VPN tunnel, and all the remote "spoke" locations would behave as VPN initiators.
```mermaid
graph TB
Responder((Responder<br/>Headquarters))
Initiator1((Initiator<br/>Remote Site 1))
Initiator2((Initiator<br/>Remote Site 2))
Initiator3((Initiator<br/>Remote Site 3))
Initiator4((Initiator<br/>Remote Site 4))
Initiator5((Initiator<br/>Remote Site 5))
Initiator1 --> Responder
Initiator2 --> Responder
Initiator3 --> Responder
Initiator4 --> Responder
Initiator5 --> Responder
```
## Login to the Firewall
You will need to access the firewall either directly on the local network at `https://<IP-of-Firewall>:4444` or remotely in Sophos Central.
## Configure an IPSec VPN Tunnel
Navigate to "**Configure > Site-to-Site VPN > Add**"
### General settings
| **Field** | **Value** |
| :--- | :--- |
| Name | `<ThisLocation> to <RemoteLocation>` |
| IP Version | `Dual` |
| Connection Type | `Tunnel Interface` (*Also known as a "Route-Based VPN"*) |
| Gateway Type | `Initiate the Connection` / `Respond Only` (*See "Best Practices" Section*) |
### Encryption
| **Field** | **Value** |
| :--- | :--- |
| Encryption Profile | `Custom_IKEv2_Initiator` / `Custom_IKEv2_Responder` (*Based on the "Gateway Type"*) |
| Authentication Type | `Preshared Key / Passphrase` |
### Gateway Settings
| **Field** | **Value** |
| :--- | :--- |
| Listening Interface | `<WAN Interface / Generally "Port2">` (*Internal IP Address*) |
| Gateway Address | `<Public IP of Remote Firewall>` |
| Local ID Type | `IP Address` (*Usually Optional*) |
| Remote ID Type | `<If the Remote Firewall has one, enter it, otherwise leave blank>` (*Usually Optional*)|
| Local Subnet | `<Leave Blank>` |
| Remote Subnet | `<Leave Blank>` |
!!! note "Tunnel IDs / Subnets"
If one side of the tunnel indicates a Local ID, you need to input that as the Remote ID on the other end of the tunnel. While Tunnel IDs are generally optional, if one side uses them, both need to.
- "Route-Based" VPNs do not need subnets indicated / configured
- "Policy-based" VPNs require subnets indicated / configured
## Configure IPSec Encryption Profile
Navigate to "**System > Profiles > IPSec Profiles > Custom_IKEv2_`<Initiator>/<Responder>`**"
!!! info "Explanation of Phases and their Relation to Initiators/Responders"
Phase 1 could be described as establishing the initial tunnel's connectivity from the Initiator to the Responder. (Local to Remote). While phase 2 would be considered individual devices establishing connections through the VPN tunnel. (Individual Endpoint Connectivity).
The responder's phase 1 & 2 lifetime values are 300 seconds longer than the initiator's phase 1 & 2 lifetime values.
=== "Initiator Phase Lifetime Values"
| **Field** | **Value** | **Notes** |
| :--- | :--- | :--- |
| Phase 1 Lifetime | *Default Value*: `28800` | `<Longer Lifetime Compared to Phase 2>` |
| Phase 2 Lifetime | *Default Value*: `14400` | `<Shorter Lifetime Compared to Phase 1>` |
=== "Responder Phase Lifetime Values"
| **Field** | **Value** | **Notes** |
| :--- | :--- | :--- |
| Phase 1 Lifetime | *Default Value + 300 Seconds*: `328800` | `<Longer Lifetime Compared to Phase 2>` |
| Phase 2 Lifetime | *Default Value + 300 Seconds*: `314400` | `<Shorter Lifetime Compared to Phase 1>` |
!!! warning "Remote / Local Phase Lifetimes"
Within the context of the remote and local VPN tunnels, the lifetime of the Phase 1 and Phase 2 encryption keys needs to be shorter on the intiator than the responder sides of the VPN tunnel.
## Repeat Steps on Remote Firewall
You will need to repeat the steps on both firewalls, so one firewall is the initiator, and one is configured as the responder. Keep special note of the admonitions regarding initiator / responder / local / remote differences.
## Connect the IPSec Tunnels
Now you need to start the tunnel on the Initiator side first, then start the tunnel on the responder side. If both sides show green status indicators, the tunnel should be active.
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/UniFi/Deploy UniFi Controller with Docker.md
+54
View File
@@ -0,0 +1,54 @@
---
tags:
- UniFi
- Networking
- Docker
---
## Purpose
The UniFi® Controller is a wireless network management software solution from Ubiquiti Networks™. It allows you to manage multiple wireless networks using a web browser.
```yaml title="docker-compose.yml"
version: "2.1"
services:
controller:
image: lscr.io/linuxserver/unifi-controller:latest
container_name: controller
environment:
- PUID=1000
- PGID=1000
#- MEM_LIMIT=1024 #optional
#- MEM_STARTUP=1024 #optional
volumes:
- /srv/containers/unifi-controller:/config
ports:
- 8443:8443
- 3478:3478/udp
- 10001:10001/udp
- 8080:8080
- 1900:1900/udp #optional
- 8843:8843 #optional
- 8880:8880 #optional
- 6789:6789 #optional
- 5514:5514/udp #optional
restart: always
networks:
docker_network:
ipv4_address: 192.168.5.140
# ipv4_address: 192.168.3.140
networks:
default:
external:
name: docker_network
docker_network:
external: true
```
```yaml title=".env"
Not Applicable
```
## Related Documentation
- [Docker Network Prerequisite](<../../Containers/Docker/Create the Docker Network.md>) — The configuration references the external `docker_network`; prepare it on the intended Docker host.
- [Ubuntu UniFi Installation Notes](<Deploy UniFi Network Server on Ubuntu.md>) — Review the separate installation approach and its incomplete status.
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/UniFi/Deploy UniFi Network Server on Ubuntu.md
+50
View File
@@ -0,0 +1,50 @@
---
tags:
- UniFi
- Networking
---
## Purpose
If you need to deploy Unifi Controller bare-metal into a virtual machine, you can do so with a few simple commands. You can feel free to reference the [original documentation](https://help.ui.com/hc/en-us/articles/220066768-Updating-and-Installing-Self-Hosted-UniFi-Network-Servers-Linux) if additional clarity is needed.
!!! note "Assumptions"
This document assumes that you are running Ubuntu Server (22.04 or higher). The instructions are not designed to accomodate RHEL-based Linux distributions.
!!! warning "INCOMPLETE DOCUMENT"
This document was originally written with the intention of comprehensively covering the deployment of the MongoDB server and Unifi Network Controller. However, I opted to use an automated scripted installation approach seen [here](https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776) that was almost turn-key instead.
```sh
apt-get update; apt-get install ca-certificates curl -y
curl -sO https://get.glennr.nl/unifi/install/install_latest/unifi-latest.sh && bash unifi-latest.sh
```
## Install Components
The installation will consist of a MongoDB server and a Unifi Network (controller) server. You will install the database first, then install the Unifi Controller second, so it can provision the newly-installed local MongoDB database server.
### General Configuration
We need to configure APT with a few commands to ensure that we can download the MongoDB and Unifi packages.
```sh
sudo apt-get update && sudo apt-get install ca-certificates apt-transport-https
echo 'deb [ arch=amd64,arm64 ] https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list
sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg
echo "deb [trusted=yes] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/3.6 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.6.list
sudo apt-get update
```
!!! note "Alternative GPG Key Installation"
If you run into issues installing the GPG key for the Unifi packages, you can alternatively run the command seen below:
```sh
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 06E85760C0A52C50
```
### MongoDB Server
Run the following commands install and enable automatic startup for the MongoDB server. Original reference documentation can be found [here](https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-ubuntu/).
```sh
```
## Related Documentation
- [Related Networking and Access Documentation](<../../../reference/Networking and Access/index.md>) — Find the connected deployments, procedures, and references for this subject.
deployments/Networking and Access/index.md
+21
View File
@@ -0,0 +1,21 @@
---
tags:
- Networking and Access
- Deployments
- Documentation
---
# Networking and Access
## Purpose
Find deployments for networking and access. Follow the subject guide to choose the relevant environment and connect this material to the other document types.
## Includes
- DNS
- NetBird
- Remote Access
- Reverse Proxies
- Sophos
- UniFi
## Follow the Subject
[Networking and Access](<../../reference/Networking and Access/index.md>) explains the relationships and offers starting points for the documented tasks.