OPNsense
OPNsense ist eine Firewall-Distribution auf der Basis des Betriebssystems FreeBSD. Im Gegensatz zu den anderen vorgestellten Software-Komponenten ist OPNsense also ein eigenständiges Betriebssystem.
Im Schulnetzkonzept kommt OPNsense aber nicht nur die Aufgabe der Firewall zu. Vielmehr ist es die Kommunikationszentrale mit u. a. folgenden Aufgaben:
- Firewall und NAT
- DNS-Server
- DHCP-Server
- NTP-Server
- Proxy-Server (nur für Schülernetz LAN_SCHUELER)
- URL-Filter (nur für Schülernetz LAN_SCHUELER)
- Reverse-Proxy
- Zertifikatsmanagement
- VPN-Server
Die aktuellen Beschreibungen basieren auf OPNsense in der Version 20.
Grundinstallation
Virtuelle Netzwerke und virtuelle Maschine erzeugen
Laden Sie zunächst das offizielle stabile amd64-DVD-Image von der OPNsense-Downloadseite herunter, entpacken Sie die heruntergeladene bz2-Datei und legen Sie die entpackte ISO-Datei auf auf dem Virtualisierungs-Host ab.
Erzeugen Sie eine neue virtuelle Maschine - Dimensionierungsbeispiel:
- OS: FreeBSD x64
- 2 CPU
- 100 GB Festplattenspeicher
- 8 GB Arbeitsspeicher
- 3 Netzwerkkarten mit Zugriff auf das interne LAN-Netzwerk mit folgenden VLANs:
- VLAN 10 untagged für LAN_MANAGEMENT
- VLAN 11 für LAN_SERVER
- VLAN 12 für LAN_SCHUELER
- VLAN 13 für LAN_LEHRER
- 1 Netzwerkkarte mit Zugriff auf das externe WAN-Netzwerk
Wählen Sie in den Einstellungen zur virtuellen Maschine als CD-Laufwerk die Datenspeicher-ISO-Datei und geben Sie den Speicherort der oben heruntergeladenen OPNsense-ISO-Datei an. Wählen Sie zudem die Option "beim Einschalten verbinden".
Nach dem Start der virtuellen Maschine öffnen Sie das Konsolenfenster. Nun sollte der textbasierte Installationsassistent von OPNsense zu sehen sein.
Installation des Betriebssystems
Folgende Schritte sind bei der Installation zu durchlaufen:
- Anmeldung mit Benutzernamen "installer" und Passwort "opnsense"
- Start der Installation mit "OK, let's go"
- Keymap mit "Change keymap" umstellen auf "de.kbd"
- Akzeptieren der Umgebungseinstellungen mit "Accept these settings"
- Geführte Installation einleiten mit "Guided installation"
- Auswahl der Festplatte, auf der OPNsense installiert werden soll
- Installationsmodus festlegen auf "GPT/UEFI mode"
- Vorgeschlagene Swap-Partitionsgröße mit "Yes" bestätigen
- root-Passwort festlegen
- Neustart des Systems
Nach dem Neustart müssen in der Regel noch die virtuellen Netzwerkkarten richtig zugewiesen werden. Die Netzwerkkarten heißen im System je nach verwendeter (virtueller) Hardware z. B. em0, em1, ... oder igb0, igb1, ... oder hn0, hn1, ...
- Melden Sie sich zunächst an der OPNsense-Konsole als root an und wählen Sie die Option "1) Assign Interfaces".
- VLANs werden hier nicht benötigt, da diese bereits über den Virtualisierungshost den virtuellen Netzwerkkarten zugewiesen wurden.
- Suchen Sie im Virtualisierungshost nach den MAC-Adressen der 4 virtuellen OPNsense-Netzwerkkarten und ordnen Sie anschließend die richtigen Netzwerkkarten-Namen zu.
Die weitere Konfiguration erfolgt überwiegend über die Web-Schnittstelle von OPNsense. Diese erreichen Sie nun innerhalb des Schulnetzes (intern) mit der auf der OPNsense-Konsole angezeigten LAN-IP-Adresse (i. d. R.: https://192.168.1.1).
Die Zugangsdaten hierfür sind:
- Benutzername: root
- Passwort: <haben Sie während des Installationsprozesses selbst vergeben>
Erste Konfiguration über die Web-Schnittstelle
Rufen Sie die Web-Schnittstelle auf und melden Sie sich an.
Beim ersten Start der Web-Oberfläche führt Sie ein Setup-Wizard durch wichtige Bestandteile der Erstkonfiguration. Hierbei sind folgende Angaben empfehlenswert:
General Information
Unbound DNS
Time Server Information
Configure WAN Interface
Configure LAN Interface
|
Nach Klick auf "Reload" werden die Einstellungen neu geladen. Sofern sie die LAN-IP-Adresse geändert haben, müssen Sie im Browser die neue IP eingeben, um die Web-Oberfläche wieder erreichen zu können.
Sie können diesen Setup-Wizard zu einem späteren Zeitpunkt erneut unter System/Setup Wizard aufrufen.
Hinweis: Sofern Sie für die WAN-Einstellungen nicht DHCP verwenden, sollten Sie unter Interfaces → WAN das IPv4-Upstream-Gateway nicht auf dem Wert "Auto" belassen, sondern explizit ein Gateway angeben. Mit der Einstellung "Auto" kann es an diversen Stellen zu unvorhersehbarem Verhalten kommen.
Installation des VMWare-Plugins
Sofern Sie OPNsense als virtuelle Maschine unter VMWare betreiben, empfiehlt sich, zur Performance-Steigerung das VMWare-Plugin zu installieren:
System/Firmware/Plugins/os-vmware → Install |
SSH-Zugriff aktivieren
Sofern Sie mit einem SSH-Client auf die Konsole (z. B. via Putty) oder das Dateisystem (z. B. via WinSCP) von OPNSense zugreifen möchten, müssen Sie den SSH-Server aktivieren:
System / Settings / Administration / Secure Shell
|
Konfiguration der Netzwerkschnittstellen und grundlegende Firewall-Regeln
Beispielhafte Netzwerk-Planung
Die Anleitungen auf diesen Seiten gehen von nachfolgender beispielhafter Netzwerkkonfiguration aus.
Diese kann selbstverständlich den eigenen Bedürfnissen angepasst werden.
Teilnetz (VLAN) |
VLAN | Netzwerkteilnehmer | IP/IP-Bereich |
10.1.254.0/24 (10 - LAN_MANAGEMENT) | 10 untagged virtueller Adapter | OPNsense-Interface LAN_MANAGEMENT | 10.1.254.1 |
10 untagged + 11 + 12 + 13 Switch-Port | Management-Interface des Virtualisierungshosts | 10.1.254.10 | |
10 untagged Switch-Port | NAS zur Datensicherung | 10.1.254.20 | |
10 untagged Switch-Port bzw. 10 untagged virtueller Adapter |
WLAN-Controller als Hardware bzw. WLAN-Controller als virtuelle Maschine |
10.1.254.30 | |
10 untagged + 12 + 13 Switch-Port | Access-Points zur Nutzung in LAN_SCHUELER und LAN_LEHRER | 10.1.254.50 - 10.1.254.99 | |
10 untagged Switch-Port bzw. 10 untagged virtueller Adapter |
DHCP-Bereich (OPNsense: Hardware-Clients) DHCP-Bereich (OPNsense: virtuelle Clients) |
10.1.1.254.200 - 10.1.1.254.254 | |
10.1.100.0/24 (11 - LAN_SERVER) | 11 virtueller Adapter | OPNsense-Interface LAN_SERVER | 10.1.100.1 |
OPNsense virtuelle IPs für HAProxy | 10.1.100.2 - 10.1.100.3 | ||
11 virtueller Adapter | Samba-Server | 10.1.100.7 | |
11 virtueller Adapter | Nextcloud-Server | 10.1.100.8 | |
11 virtueller Adapter | Collabora-Server für Nextcloud | 10.1.100.9 | |
11 untagged Switch-Port | OPNsense-DHCP-Bereich (OPNsense: Hardware-Clients) | 10.1.100.200 - 10.1.100.254 | |
11 virtueller Adapter | OPNsense-DHCP-Bereich (OPNsense: virtuelle Clients) | 10.1.100.200 - 10.1.100.254 | |
10.1.0.0/20 (12 - LAN_SCHUELER) | 12 virtueller Adapter | OPNsense-Interface LAN_SCHUELER | 10.1.0.1 |
12 virtueller Adapter | FOG-Server | 10.1.1.1 | |
12 untagged Switch-Port | OPNsense-DHCP-Bereich (kabelgebundene Clients) | 10.1.11.1 - 10.1.15.254 | |
12 virtueller Adapter bzw. | OPNsense-DHCP-Bereich (virtuelle Clients) | 10.1.11.1 - 10.1.15.254 | |
s. Access-Points | OPNsense-DHCP-Bereich (WLAN-Clients) | 10.1.11.1 - 10.1.15.254 | |
10.1.16.0/20 (13 - LAN_LEHERER) | 13 virtueller Adapter | OPNsense-Interface LAN_LEHRER | 10.1.16.1 |
s. Access-Points | DHCP-DHCP-Bereich (WLAN-Clients) | 10.1.27.1 - 10.1.31.254 |
Hinweise:
- Subnetzmaske und Standardgateway der Netzwerkteilnehmer ist die IP des jeweils zugehörigen OPNsense-Interfaces.
- Aus Gründen der leichteren technischen Umsetzbarkeit sollte sich der FOG-Server im gleichen Teilnetz wie damit zu verwaltenden Clients befinden.
- Auf eine klassische DMZ wurde bewusst verzichtet: besonders schützenswerte Netzwerkteilnehmer sind in eigenen Teilnetzen (LAN_MANAGEMENT und LAN_SERVER) untergebracht und mit entsprechenden Firewallregeln abgeschirmt. Für Schüler und Kollegen zugängliche Dienste sind sowohl von innerhalb als auch von außerhalb des Schulhauses nur über den HAProxy zugänglich.
Interfaces für die Teilnetze anlegen, zuweisen und konfigurieren
Sofern noch nicht geschehen müssen die virtuellen Netzwerkkarten von OPNsense unter Interfaces/Assignments Netzwerk-Interfaces zugewiesen werden. Folgende Interfaces werden benötigt:
- LAN_MANAGEMENT
- LAN_SERVER
- LAN_SCHUELER
- LAN_LEHRER
- WAN
Im Detail werden die internen Netzwerkschnittstellen wie folgt konfiguriert:
Interfaces/LAN_MANAGEMENT
Interfaces/LAN_SERVER
Interfaces/LAN_SCHUELER
Interfaces/LAN_LEHRER
|
Firewallregeln für LAN_MANAGEMENT, LAN_SERVER, LAN_SCHUELER, LAN_LEHRER
Auf dieser Seite werden alle notwendigen Firewallregeln erläutert. Löschen sie unbedingt alle standardmäßig erzeugten Regeln der Form "Default allow XXX to any rule", da diese - ohne entsprechende vorherige Blockregeln - zu Sicherheitslücken führen können.
Für das grundsätzliche Verständnis der Firewall-Funktionalität von OPNSense sei gesagt, dass...
- Regeln je Schnittstelle definiert werden.
- ohne jegliche Regeln sämtlicher Datenverkehr auf der Schnittstelle geblockt wird.
- bei auftretendem Datenverkehr auf einer Schnittstelle deren Regeln solange der Reihe nach von oben beginnend solange abgearbeitet werden, bis eine Regel zutrifft.
Zunächst wird ein Alias mit dem Namen RFC1918 angelegt. Dieser steht für alle privaten Netzwerke und wird später an diversen Stellen bei der Definition von Firewall-Regeln benötigt:
Firewall/Aliases → Add
|
Anfragen ausgehend vom Netzwerk LAN_MANAGEMENT sollen Grundsätzlich in alle anderen Netzwerke (auch das Internet) erlaubt sein.
Firewall/Rules/LAN_MANAGEMENT → Add
|
Ausgehend von den Netzwerken LAN_SERVER, LAN_SCHUELER und LAN_LEHRER sollen Anfragen ins Internet sowie an die Firewall selbst (z. B. für DNS- oder NTP-Dienste) erlaubt sein.
Hinweise:
- Die Erzwingung der Kommunikation über einen Webfilter im Netzwerk LAN_SCHUELER wird weiter unten gezeigt. Trotzdem sollen auch für dieses Netzwerk die nachfolgenden Regeln eingerichtet werden.
- Für die Erlaubnis der Internet-Kommunikation benötigen wir den oben erzeugten Alias RFC1918 und invertieren ihn (alle privaten Netzwerke → invertiert: Internet).
Firewall/Rules/LAN_SERVER sowie Firewall/Rules/LAN_SCHUELER sowie Firewall/Rules/LAN_LEHRER → Add
Firewall/Rules/LAN_SERVER sowie Firewall/Rules/LAN_SCHUELER sowie Firewall/Rules/LAN_LEHRER → Add
|
Die Kommunikation von LAN_LEHRER ins Netzwerk LAN_SCHUELER soll grundsätzlich gestattet werden (z. B. zur Benutzung von Druckern, Cast-Sticks etc.).
Firewall/Rules/LAN_LEHRER
|
DNS-Anfragen auf den Netzwerken LAN_SCHUELER und LAN_LEHRER sollen grundsätzlich von OPNSense beantwortet werden.
Firewall/NAT/Port Forward → Add
|
Multicast DNS Repeater zwischen LAN_SCHUELER und LAN_LEHRER
Beim Schulnetzkonzept ist vorgesehen, dass Geräte wie Drucker oder Cast-Lösungen (z. B. HDMI-Sticks, Airserver, ...) im Netzwerk LAN_SCHUELER beheimatet sind. Damit diese Geräte über den Bonjour-Dienst auch vom Netzwerk LAN_LEHRER aus automatisch entdeckt werden können, ist die Installation und Konfiguration des MDNS-Repeater-Moduls erforderlich.
Installation:
System/Firmware/Plugins/os-mdns-repeater → Install |
Konfiguration
|
Konfiguration des DHCP-Servers
DHCP für LAN_SCHUELER
Damit im Schulnetz angeschlossene Clients IP-Adressen und weitere Netzwerkinformationen automatisiert zugewiesen bekommen, muss der DHCP-Server für LAN_SCHUELER aktiviert und konfiguriert werden.
Begeben Sie sich hierzu zu Services/DHCPv4/LAN_SCHUELER und tätigen Sie die folgenden Einstellungen:
General Options
NTP
Enable network booting
DHCP Static Mappings for this Interface
|
DHCP für LAN_LEHRER, LAN_MANAGEMENT und LAN_SERVER
Auch wenn in den Subnetzen LAN_MANAGEMENT und LAN_SERVER überwiegend manuell festgelegte IP-Adressen anzutreffen sind, empfiehlt sich auch für diese, den DHCP-Server zu aktivieren, sodass mit angeschlossenen Clients schnell und unkompliziert eine erste Kommunikation aufgebaut werden kann.
Beispiel-Konfigurationen für DHCPv4 und LAN_LEHRER, LAN_MANAGEMENT bzw. LAN_SERVER
Services/DHCPv4/LAN_LEHRER
Services/DHCPv4/LAN_MANAGEMENT
Services/DHCPv4/LAN_SERVER
|
Konfiguration der zur Verfügung stehenden Internetgeschwindigkeit
Durch den Shaper kann OPNsense im Sinne des Quality of Service (QoS) die zur Verfügung stehende Internetbandbreite bestmöglich ausnutzen. Folgender Ansatz zeigt eine Gleichverteilung der zur Verfügung stehenden Bandbreite unter allen Netzwerkteilnehmern.
Firewall / Shaper / Settings / Pipes (Leitungen)
Firewall / Shaper / Settings / Queues (Warteschlangen)
Firewall / Shaper / Settings / Rules (Regeln für die Bandbreitenverwendung)
|
Für den Shaper sind zahlreiche andere Einstellungsmöglichkeiten denkbar - z. B. für die Priorisierung von Voice-Over-IP-Telefonaten o. ä.
Konfiguration des Proxy-Servers
Das Schulnetzkonzept geht davon aus, dass der Aufruf von Webseiten aus dem Netz LAN_SCHUELER nur über den zwischengeschalteten Proxy möglich ist. Nur dann können mithilfe des URL-Filters squidGuard (s. weiter unten) Webseitenaufrufe via Port 80 (http) bzw. Port 443 (https) effektiv gefiltert werden. Um das Handling mit dem Proxy für alle User so einfach wie möglich zu gestalten, wir dieser im transparenten Modus betrieben. Somit sind an den Clients keinerlei Einstellungen zu tätigen bzw. zu verteilen.
Damit auch verschlüsselte https-Anfragen datenschutzkonform - also ohne das Aufbrechen von Zertifikaten - über den transparenten Proxy abgewickelt werden können, verwendet das Schulnetzkonzept die Möglichkeit der Filterung über SNI (Server Name Indication): Bevor ein Browser eine verschlüsselte Verbindung zu einem Webserver aufbaut, sendet er diesem den gewünschten Host (FQDN) unverschlüsselt. Diese Information kann vom transparentem Proxy ausgelesen und für die Filterung genutzt werden.
Folgende Anpassungen an den Default-Einstellungen sind zu tätigen:
Services / Web Proxy / Administration
|
http- und https-Anfragen an den Proxy weiterleiten
Weiterleitung von Web-Anfragen an den Proxy
Die beiden Haupt-Ports für Aufrufe von externen Internetseiten (RFC1918 invertiert!) werden an den Proxy weitergeleitet:
Firewall / NAT / Port Forward 1. Regel
2. Regel
|
Achten Sie darauf, dass die soeben erstellten Regeln unter Firewall / Rules / LAN_SCHUELER oberhalb der Regeln "Allow firewall" und "Allow not-private networks (internet)" erscheinen. Verschieben sie diese gegebenenfalls.
Konfiguration des Webfilters
Hauptziel des Einsatzes eines Proxys an Schulen ist die Verwendung in Kombination mit einem URL-Filter, welcher Schüler vor ungewünschten Inhalten im Netz schützen soll.
URL-Filter-Liste erzeugen und konfigurieren
Die "UT1-web-categorization-list der Université Toulouse ist eine frei verfügbare, regelmäßig aktualisierte und in Form von Kategorien organisierte Liste, welche zusammen mit dem OPNsense-Webfilter verwendet werden kann, um Webseitenaufrufe themenbasiert (z. B. Pornographie, Gewaltverherrlichung, soziale Netzwerke, ...) zu sperren. An dieser Stelle muss erwähnt werden, dass dies zwar sehr gut funktioniert, es eine 100%ige Absicherung gegenüber Webinhalten aber niemals geben kann.
Services / Web Proxy / Administration / Remote Access Control Lists → Hinzufügen einer Liste durch Klick auf das Plus-Symbol
→ Save changes → Download ACLs |
Das Herunterladen der Liste kann eine Weile dauern. Nach erfolgtem Download können Sie Ihre soeben angelegte Liste (shallalist) nochmals editieren und unter categories jene Themenfelder auswählen, welche vom Schulnetz aus gesperrt sein sollen.
Sperrempfehlungen (Sperrungen sollten in Absprache mit Schulleitung und Kollegium erfolgen):
|
Blacklist automatisch aktualisieren
Beispiel: wöchentliche Aktualisierung der Shallalist am Montag um 00:00 Uhr
Services / Web Proxy / Administration / Remote Access Control List → Schedule with Cron
|
Benutzerdefinierte Whitelists und Blacklists
Services / Web Proxy / Administration / Forward Proxy / Access Control List
|
Damit Benutzer den URL-Filter nicht einfach dadurch umgehen können, dass sie statt der URL die korrespondierende IP einer Webseite in die Adresszeile des Browsers eingeben, kann die Eingabe von IP-Adressen als URL mit folgendem regulären Ausdruck gesperrt werden:
Services / Web Proxy / Administration / Forward Proxy / Access Control List
|
Vollqualifizierte Domänennamen für Schulnetzdienste
Subdomains beim Webhoster einrichten
Die Zugriffe auf Dienste im Schulnetz sollen aus Gründen der Sicherheit ausschließlich verschlüsselt erfolgen. Um hierfür gültige Zertifikate generieren zu können, ist für jeden Dienst ein vollqualifizierter öffentlicher Domänenname erforderlich. Somit ist es auch möglich, gesichert auf Dienste von außen zuzugreifen (kann auf Wunsch unterbunden werden).
Die meisten Schulen haben sich für ihre Schulhomepage bereits einen entsprechenden Domänennamen (hier im weiteren als Beispiel: ihre-schule.de) gesichert. Sofern Ihr Webhoster dies unterstützt, können Sie für die Dienste im Schulnetz entsprechende Subdomains anlegen, welche dann auf den Internetanschluss der Schule geleitet werden sollen - z. B.:
- Webdienste
- nextcloud.ihre-schule.de (Zugriff auf die Nextcloud)
- www.nextcloud.ihre-schule.de (Viele User geben "www" als Subdomain vor dem Dienst ein. Deshalb sollte die Nextcloud auch via "www..." erreichbar sein.
- collabora.ihre-schule.de (Online-Office für Nextcloud)
- usermanagement.ihre-schule.de (Zugriff auf den LDAP-Account-Manager zur Benutzerverwaltung)
- selfservice.ihre-schule.de (Zugriff auf den Self-Service-Password-Dienst)
- fog.ihre-schule.de (Zugriff auf den Image-Server FOG)
- Andere Dienste
- ldap.ihre-schule.de (Zugriff für externe ldap-Anfragen)
- radius.ihre-schule.de (Zertifikat für den Radius-Server)
OPNsense wird im Abschnitt "Installation und Konfiguration des Reverse-Proxy-Servers" so konfiguriert, dass die angegebenen Domänennamen sowohl von innerhalb des Schulnetzes und wenn gewünscht auch von außerhalb für den Zugriff auf die Dienste verwendet werden können. So nutzt z. B. ein Schüler sowohl von zu Hause als auch vom Schulnetz aus die Nextcloud durch Angabe der URL https://nextcloud.ihre-schule.de (und nicht durch Angabe einer IP-Adresse).
Subdomains beim Webhoster weiterleiten
Damit die angelegten Subdomains auf die IP-Adresse des Internetanschlusses für das Schulnetz zeigen, gibt es zwei Möglichkeiten:
Möglichkeit 1: Sie erhalten eine feste IP-Adresse von Ihrem Internet-Provider → A-Record
In diesem Fall legen Sie beim Webhoster unter den Nameservereinstellungen für jede angelegte Subdomain einen A-Record mit der festen IP-Adresse des Schulnetz-Internetanschlusses fest.
Möglichkeit 2: Die IP-Adresse des Schulnetz-Internetanschlusses ändert sich in regelmäßigen Abständen → CNAME-Record
In diesem Fall benötigen Sie einen DynDNS-Anbieter, aus dessen Pool Sie sich einen Domänennamen reservieren, der auf die IP-Adresse des Schulnetz-Internetanschlusses zeigt. Damit die regelmäßig stattfindenden Änderungen der IP-Adresse für den beim DynDNS-Anbieter reservierten Domänennamen aktualisiert werden, können Sie den von OPNsense integrierten Aktualisierungs-Client verwenden:
Services / Dynamic DNS → Add
|
Nach erfolgreicher Einrichtung des DynDNS-Dienstes legen Sie beim Webhoster unter den Nameservereinstellungen für jede angelegte Subdomain einen CNAME-Record mit dem DynDNS-Domänennamen des Schulnetz-Internetanschlusses fest.
Installation und Konfiguration des Reverse-Proxy-Servers
Warum eigentlich ein Reverse-Proxy?
Der Reverse-Proxy entscheidet für an ihn gerichtete Anfragen, ob und an wen er diese Weiterleitet.
Sofern man nur einen Dienst von außen zugänglich machen möchte (z. B. die Nextcloud), könnte man auch den einfacheren Weg wählen und im Router mit entsprechend NAT-Regeln (z. B. für die Ports 80 und 443) arbeiten.
Im Schulnetzkonzept gibt es aber gute Gründe dafür, einen Reverse-Proxy einzusetzen:
- Es gibt mehrere Dienste, die von außen über die gleichen Ports zugänglich sein sollen (z. B. Nextcloud, Collabora, Passwort-Service), sodass NAT-Regeln hierfür nicht ausreichen.
- Der Reverse-Proxy wird im Schulnetzkonzept auch dafür eingesetzt, für Anfragen die dazu passenden Zertifikate bereitzustellen. Dies entlastet den dahinter liegenden Webserver (z. B. den der Nextcloud) enorm.
- Der Reverse-Proxy wird auch für Anfragen von innerhalb des Schulnetzes verwendet, sodass Dienste wie die Nextcloud auch von dort verschlüsselt über ihren vollqualifizierten Domänennamen erreichbar sind und intern und nicht über das Internet geroutet werden.
Installation und Konfiguration des HAProxy-Plugins
Der Reverse-Proxy mit Namen HAProxy muss zunächst installiert werden:
System / Firmware / Plugins / os-haproxy → Install |
Anschließend muss der HAProxy aktiviert werden:
Services / HAProxy / Settings / Service Settings
|
Einrichtung virtueller IPs und zugehöriger Namen (Aliases) für den HAProxy
Um zwischen Anfragen an den HAProxy unterscheiden zu können, die ausschließlich von intern (lan) oder von intern und extern (lan_wan) zulässig sind, werden zwei virtuelle LAN-IP-Adressen benötigt, auf denen der HAProxy lauschen kann:
Interfaces / Virtual IPs / Settings → Add 1. Virtual IP (HAProxy-Interface für interne und externe Anfragen)
2. Virtual IP (HAProxy-Interface ausschließlich für interne Anfragen)
|
Zusätzlich werden für beide IP-Adressen Alias-Namen in OPNsense hinterlegt, auf die später zugegriffen wird:
Firewall / Aliases → Add 1. Alias (HAProxy-Interface für interne und externe Anfragen)
2. Alias (HAProxy-Interface ausschließlich für interne Anfragen)
|
Interne und externe Anfragen Webserveranfragen (Ports 80/443) auf den HAProxy weiterleiten
Sowohl externe als auch interne HTTP- und HTTPS-Anfragen sollen auf die entsprechenden HAProxy-Interfaces weitergeleitet werden.
Weiterleitung externer Anfragen
Firewall / NAT / Port Forward → Add 1. Weiterleitung (auf Port 80)
2. Weiterleitung (auf Port 443)
|
Weiterleitung interner Anfragen
Damit schulhausinterne Aufrufe der Webdienste direkt beim Reverse-Proxy landen und nicht über das Internet geroutet werden, müssen entsprechende Nameserver-Weiterleitungen zur virtuellen IP-Adresse des gewünschten HAProxy-Moduls existieren. Sofern der Webdienst nur innerhalb des Schulhauses erreichbar sein soll, leiten Sie zur virtuellen IP von HAProxy_lan ansonsten zu HAProxy_lan_wan weiter.
Beispiel für den Webdienst Nextcloud, welcher auch von außen erreichbar sein soll:
Services / Unbound DNS / Overrides / Host Overrides → Add
|
Firewallregeln für LAN_LEHRER
Vom Netzwerk LAN_SCHUELER aus werden die Anfragen zum HAProxy über den Webproxy (Squid) geleitet. Da im Netzwerk LAN_LEHRER kein Webproxy aktiv ist, sind zwei zusätzliche Regeln erforderlich:
Firewall/Rules/LAN_LEHRER → Add
Firewall/Rules/LAN_LEHRER → Add
|
Einrichtung von Real Servers
Real Servers sind jene Dienste, welche hinter dem HAProxy erreicht werden sollen.
Richten Sie für jeden Ihrer Webdienste - unabhängig davon, ob dieser von außen erreichbar sein soll oder nicht - einen Real Server ein:
- nextcloud.ihre-schule.de
- collabora.ihre-schule.de
- usermanagement.ihre-schule.de
- selfservice.ihre-schule.de
- fog.ihre-schule.de
Beispiel für den Webdienst nextcloud.ihre-schule.de:
Services / HAProxy / Settings / Real Servers → Add
|
Einrichtung von Backend Pools
Mit einem Backend Pool können ein oder mehrere Real Server gebündelt werden. Auch wenn für jeden Webdienst jeweils nur einen Real Server (z. B. gibt es nur einen Nextcloud-Server) bereitgehalten wird, muss an dieser Stelle für jeden Dienst ein Backend Pool eingerichtet werden.
Beispiel für den Webdienst nextcloud.ihre-schule.de:
Services / HAProxy / Settings / Virtual Services / Backend Pools → Add
|
Einrichtung der Public Services
Die Public Services des HAProxys sind die Anlaufstellen, die interne bzw. externe Anfragen entgegennehmen.
Für das Schulnetzkonzept werden 3 Public Services benötigt:
- eines für interne und externe Anfragen über http,
- eines für interne und externe Anfragen über https und
- eines für ausschließlich interne Anfragen über https.
Einrichtung des Public Service für interne und externe Anfragen über http
Services / HAProxy / Settings / Virtual Services / Public Services → Add
|
Einrichtung des Public Service für interne und externe Anfragen über https
Services / HAProxy / Settings / Virtual Services / Public Services → Add
|
Einrichtung des Public Service für ausschließlich interne Anfragen über https
Services / HAProxy / Settings / Virtual Services / Public Services → Add
|
Einrichtung von Conditions
Conditions sind vordefinierte Bedingungen die für die späteren Regeln für die Reaktionen des HAProxy notwendig sind.
Zunächst benötigen Sie für jeden Webdienst eine Bedingung, die greift, falls eine Anfrage mit dem entsprechenden Domänennamen an den HAProxy gerichtet wird.
Beispiel für den Webdienst nextcloud.ihre-schule.de:
Services / HAProxy / Settings / Rules & Checks / Conditions → Add
|
Weiterhin benötigen Sie eine Bedingung, mit der der HAProxy erkennt, dass eine Anfrage an ihn nicht verschlüsselt erfolgt ist:
Services / HAProxy / Settings / Rules & Checks / Conditions → Add
|
Einrichtung von Rules
Rules sind vordefinierte Regeln, wie der HAProxy bei Eintreten einer oder mehrere Bedingungen reagieren soll.
Zunächst benötigen Sie für jeden Webdienst eine Regel, die den HAProxy dazu verleitet, dass er eine an ihn gerichtete Anfrage an den entsprechenden Backend Pool weiterleitet.
Beispiel für den Webdienst nextcloud.ihre-schule.de:
Services / HAProxy / Settings / Rules & Checks / Rules → Add
|
Weiterhin benötigen Sie eine Regel, die nicht verschlüsselte htttp-Anfragen auf https umleitet:
Services / HAProxy / Settings / Rules & Checks / Rules → Add
|
Zuweisung von Rules zu Backend-Pools
Da jede http-Anfrage an einen der Webdienste auf https umgeleitet werden soll, weisen sie jedem Backend Pool dir Rule redirect_ssl zu.
Beispiel für den Backend Pool nextcloud_backend:
HAProxy / Settings / Virtual Services / Backend Pools / nextcloud_backend → Edit Select Rules: redirect_ssl |
Zuweisung von Rules zu Public Services
Der Public Service http_lan_wan soll alle an ihn gestellte Anfragen an den entsprechenden Backend-Poll weiterleiten:
HAProxy / Settings / Virtual Services / Public Services / http_lan_wan → Edit Select Rules: z. B.: nextcloud fog usermanagement opnsense collabora |
Der Public Service https_lan soll nur auf https-Anfragen reagieren, die ausschließlich intern zugänglich sein sollen:
HAProxy / Settings / Virtual Services / Public Services / https_lan → Edit Select Rules: z. B.: fog usermanagement opnsense |
Der Public Service https_lan_wan soll auf sowohl interne als auch externe https-Anfragen reagieren:
HAProxy / Settings / Virtual Services / Public Services / https_lan_wan → Edit Select Rules: z. B.: nextcloud collabora |
Wichtige Einstellungen für die Nextcloud
Sofern Sie den HAProxy zur Weiterleitung von Anfragen an eine Nextcloud verwenden, müssen Anfragen an die Caldav- und die Carddav-Dienste der Nextcloud noch berücksichtigt werden.
Einrichtung weiterer Conditions
Services / HAProxy / Settings / Rules & Checks / Conditions → Add 1. Condition:
2. Condition:
|
Einrichtung einer weiteren Rule
Services / HAProxy / Settings / Rules & Checks / Rules → Add
|
Zuweisung der Rule zu Public Services
1. Public Service HAProxy / Settings / Virtual Services / Public Services / http_lan_wan → Edit Hinzufügen bei Select Rules: nextcloud-caldav-carddav 2. Public Service HAProxy / Settings / Virtual Services / Public Services / https_lan_wan → Edit Hinzufügen bei Select Rules: nextcloud-caldav-carddav |
Wenn Sie Nextcloud Talk/Spreed verwenden wollen, müssen Sie die Server-Timeout-Einstellung des HAProxy etwas hochsetzen, um ein Timeout des Signaling-Servers zu umgehen.
Hochsetzen des Server-Timeouts
Services / HAProxy / Settings / Settings / Default Parameters Server Timeout: 40s |
Installation und Konfiguration der automatisierten Zertifikatsverwaltung
Mit dem Let's-Encrypt-Plugin können Sie für Ihre Webdienste kostenlos gültige X.509-Zertifikate von der Zertifizierungsstelle Let's Encrypt generieren. Dies ermöglicht eine verschlüsselte Nutzung Ihrer Webdienste über https ohne Zertifikatswarnungen. Auch für verschlüsselte ldap-Anfragen an den Samba-Server können Let's-Encrypt-Zertifikate eingesetzt werden.
Installation und Konfiguration des acme-Plugins
Das Plugin muss zunächst über die Firmwareverwaltung installiert werden:
System / Firmware / Plugins / os-acme-client → Install |
Grundkonfiguration
Services / Let's Encrypt / Settings
|
Anlage eines Let's-Encrypt-Kontos
Services / Let's Encrypt / Accounts → Add
|
Anlage einer Validierungsmethode
Services / Let's Encrypt / Validadtion Methods → Add
|
Anlage von Zertifikaten
Richten Sie für jeden Ihrer Webdienste - auch für jene, die nur innerhalb des Schulhauses erreichbar sein sollen - ein Zertifikat ein.
Beispiel für den Webdienst Nextcloud:
Services / Let's Encrypt / Certificates → Add
|
Den HAProxy für die Verwendung von Let's Encrypt konfigurieren
Durch die Angaben unter Settings und bei der Validierungsmethode http-01 hat das Let's-Encrypt-Plugin entsprechende Eintragungen im HAProxy vorgenommen. Überprüfen Sie deren Anwesenheit:
|
Stellen Sie sicher, dass im Public Service http_lan_wan die Regel redirect_acme_challenges an erster Stelle auftaucht. Sie können die Reihenfolge per Drag & Drop ändern:
HAProxy / Settings / Virtual Services / Public Services → http_lan_wan
|
Zertifikate generieren
Nachdem der HAProxy für die ACME-Challenge-Anfragen konfiguriert ist, können nun die Zertifikate generiert werden:
Services / Let's Encrypt / Certificates → Issue/Renew Certificates Now (bzw. Klick auf das Neu-Laden-Symbol neben jedem Zertifikat) |
Ob das Generieren der Zertifikate funktioniert hat, kann unter Services / Let's Encrypt / Log File nachverfolgt werden. Suchen Sie bei Problemen nach dem Schlagwort "error".
Zertifikate im HAProxy hinterlegen
Damit der HAProxy die mit Let's Encrypt generierten Zertifikate nun bei https-Anfragen bereitstellt, müssen diese bei den entsprechenden Public-Services hinterlegt werden:
Services / HAProxy / Settings / Virtual Services / Public Services / https_lan (Dienst für ausschließlich interne https-Anfragen)
Services / HAProxy / Settings / Virtual Services / Public Services / https_lan_wan (Dienst für interne und externe https-Anfragen)
|
Besonderheit: Zertifikat für verschlüsselte ldap-Anfragen an den Samba-Server
Da der HAProxy die ldap-Anfragen nicht verarbeiten kann, wird der betroffene Port 636 für Anfragen von außen über eine NAT-Regel an den Samba-Server weitergeleitet:
Firewall / NAT / Port Forward→ Add
|
Die Zertifikatsgenerierung für ldap.ihre-schule.de soll aber trotzdem über das Let's-Encrypt-Plugin nach obigen Beispiel erfolgen.
Da der HAProxy die ldap-Anfragen aber nicht entgegennimmt, muss der Samba-Server selbst die Zertifikatsinformationen erhalten und ausgeben. Nachdem das Let's-Encrypt-Plugin das Zertifikat für ldap.ihre-schule.de generiert bzw. erneuert hat, soll es die Zertifikatsdateien also auf den Samba-Server kopieren. Hierzu sind die nachfolgenden Schritte erforderlich:
SSH-Kommunikation zwischen Samba-Server und OPNsense vorbereiten
Siehe hierzu die Beschreibung zum Samba-Server.
Skript zum Kopieren der Zertifikate
Damit nach einer Erneuerung des Zertifikats von ldap.ihre-schule.de durch das Let's-Encrypt-Plugin dieses auf dem LDAP-Server landet, ist ein Skript erforderlich, welches die Dateien von OPNsense auf den LDAP-Server kopiert, entsprechende Dateiberechtigungen setzt und den Domänen-Controller neu startet.
Dieses Skript wird in OPNsense so hinterlegt, dass es später an entsprechender Stelle in der Webmin-Oberfläche ausgewählt werden kann.
Achten Sie bei der Verwendung der nachfolgenden Datei auf die Verwendung der richtigen IP-Adresse und Pfade.
vi /usr/local/opnsense/service/conf/actions.d/actions_ldapserver.conf
Datei /usr/local/opnsense/service/conf/actions.d/actions_ldapserver.conf
[ldap-upload-certs]
command:scp -i /root/.ssh/id_rsa_samba /var/etc/acme-client/home/ldap.ihre-schule.de/* root@10.1.100.7:/etc/samba/tls
parameters:
type:script
message:copy certificates to ldap-server
description:LDAP-Server - Copy Certificates
[ldap-restart-dc]
command:ssh -i /root/.ssh/id_rsa_samba root@10.1.100.7 "chmod -R 0755 /etc/samba/tls && chmod 0600 /etc/samba/tls/*.key && service samba-ad-dc restart"
parameters:
type:script
message:restarting ldap-server-dc
description:LDAP-Server - Restart DC
Damit das Skript im System zur Verfügung steht muss der Dienst configd neu gestartet werden:
service configd restart
Skript beim Let's-Encrypt-Zertifikat hinterlegen
Zunächst müssen die beiden Aktionen des Skriptes als Automatisierungsaufgaben im Let's-Encrypt-Plugin definiert werden:
Services / Let's Encrypt / Automation → Add
|
Anschließend werden die beiden Automatisierungsaufgaben dem Zertifikat ldap.ihre-schule.de zugeordnet.
Services / Let's Encrypt / Certificates / ldap.ihre-schule.de → edit
|
Somit werden nach Erneuerung des Zertifikats für ldap.ihre-schule.de automatisch die Zertifikatsdateien auf den LDAP-Server kopiert und anschließend der DC-Dienst neu gestartet.
Besonderheit: Zertifikat für verschlüsselte Anfragen an den Radius-Server
Nachdem das Let's-Encrypt-Plugin das Zertifikat für radius.ihre-schule.de generiert bzw. erneuert hat, soll es die Zertifikatsdateien also auf den Radius-Server kopieren. Hierzu sind die nachfolgenden Schritte erforderlich:
SSH-Kommunikation zwischen Radius-Server und OPNsense vorbereiten
Siehe hierzu die Beschreibung zum Samba-Server.
Skript zum Kopieren der Zertifikate
Damit nach einer Erneuerung des Zertifikats von radius.ihre-schule.de durch das Let's-Encrypt-Plugin dieses auf dem Radius-Server landet, ist ein Skript erforderlich, welches die Dateien von OPNsense auf den Radius-Server kopiert, entsprechende Dateiberechtigungen setzt und den Radius-Server neu startet.
Dieses Skript wird in OPNsense so hinterlegt, dass es später an entsprechender Stelle in der Webmin-Oberfläche ausgewählt werden kann.
Achten Sie bei der Verwendung der nachfolgenden Datei auf die Verwendung der richtigen IP-Adresse und Pfade.
vi /usr/local/opnsense/service/conf/actions.d/actions_radiusserver.conf
Datei /usr/local/opnsense/service/conf/actions.d/actions_radiusserver.conf
[radius-upload-certs]
command:scp -i /root/.ssh/id_rsa_samba /var/etc/acme-client/home/radius.ihre-schule.de/* root@10.1.100.7:/etc/freeradius/3.0/certs/radius.ihre-schule.de
parameters:
type:script
message:copy certificates to radius-server
description:RADIUS-Server - Copy Certificates
[radius-restart]
command:ssh -i /root/.ssh/id_rsa_samba root@10.1.100.7 "chmod -R 0755 /etc/freeradius/3.0/certs/radius.ihre-schule.de && chmod 0640 /etc/freeradius/3.0/certs/radius.ihre-schule.de/*.key && chown root:ssl-cert /etc/freeradius/3.0/certs/radius.ihre-schule.de/*.key && service freeradius restart"
parameters:
type:script
message:restarting radius-server
description:RADIUS-Server - Restart
Damit das Skript im System zur Verfügung steht muss der Dienst configd neu gestartet werden:
service configd restart
Skript beim Let's-Encrypt-Zertifikat hinterlegen
Zunächst müssen die beiden Aktionen des Skriptes als Automatisierungsaufgaben im Let's-Encrypt-Plugin definiert werden:
Services / Let's Encrypt / Automation → Add
|
Anschließend werden die beiden Automatisierungsaufgaben dem Zertifikat radius.ihre-schule.de zugeordnet.
Services / Let's Encrypt / Certificates / radius.ihre-schule.de → edit
|
Somit werden nach Erneuerung des Zertifikats für radius.ihre-schule.de automatisch die Zertifikatsdateien auf den Radius-Server kopiert und dieser anschließend neu gestartet.
Installation und Konfiguration des OpenVPN-Servers
Grundinstallation
Mithilfe des OpenVPN-Servers können Sie z. B. als Administrator von außen auf das interne Netzwerk zugreifen.
Für die Einrichtung des OpenVPN-Servers steht ein Wizard zur Verfügung, der auch die notwendigen Firewall-Einstellungen hinterlegt:
VPN / OpenVPN / Servers → Use a wizard to to setup a new server
|
Anlegen einer VPN-Gruppe
Durch Anlage einer Gruppe für den VPN-Zugriff, kann man folgende Festlegungen tätigen:
- Berechtigung für die VPN-Einwahl nur für Mitglieder der Gruppe
- Beschränkung der OPNsense-Web-Oberfläche für die Gruppenmitglieder, sodass zugehörige Benutzer lediglich ihr eigenes Passwort ändern können
System / Access / Groups → Add
|
Anlegen von VPN-Benutzern
System / Access / Users → Add
|
Export der VPN-Zugangsdaten für angelegte User
VPN / OpenVPN / Client Export
|
Unterhalb der Einstellungsmöglichkeiten können für angelegte Benutzer deren individuellen Zugangsdaten heruntergeladen werden. Ggf. wählen Sie hierzu bei Export Type eine passende Downloadmöglichkeit.
Client-Installationsdateien und Konfigurationsdateien ausgeben
Nach Anlage eines VPN-Users können Sie diesem für sein System (z. B. Windows, Mac, ...) personalisierte Dateien für Installation und Konfiguration des OpenVPN-Clients aushändigen:
VPN / OpenVPN / Client Export → OpenVPN Clients |
Letzte Aktualisierung der Seite: 2024-02-16 14:17