Metainformationen zur Seite
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
sysbetr:reverse_proxy_opnsense [2020/04/17 17:52] – [Konfiguration von Letsencrypt (acme-client) und von HAProxy] cb | sysbetr:reverse_proxy_opnsense [2020/05/05 12:06] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====Reverse-Proxy auf Basis von OPNsense==== | + | Dies Systembetreuungs-Seiten sind umgezogen zu **[[https:// |
- | ===Grund=== | + | |
- | Ich möchte ((Der Wechsel ist u.a. ein Gebot der Vernunft, da z.B. die Weiterentwicklung | + | |
+ | Diese Seite finden Sie dort als **[[https:// | ||
- | ===Übersicht zum Aufbau des Netzes=== | ||
- | {{: | ||
- | |||
- | Die Debian-Web-Server, | ||
- | Der benachbarte AdminPC kann irgendein Betriebssystem haben - solange ein Browser zur Firewallsteuerung läuft. \\ | ||
- | Die roten Netze existieren alle nur innerhalb des KVM-Systems als virtuelle Netze (ohne DHCP oder Hostverbindung). Von oben sind es Schulnetz, Demonetz und das winzige Management-Netz. | ||
- | |||
- | So erfolgt der Zugriff aus dem Internet: Vom Clients ist zuerst die Fritzbox zu " | ||
- | |||
- | ===Installation=== | ||
- | Plane das Netzwerk und die Serveradressen! Die restlichen Maschinen außer OPNsense können bereits installiert sein, man kann sie ja dann in den virtuellen Netzen verschieben. | ||
- | |||
- | IP-Adressen innerhalb des KVM-Servers: | ||
- | ^ Maschine | ||
- | | OPNsense | ||
- | | OPNsense | ||
- | | OPNsense | ||
- | | OPNsense | ||
- | | Admin-PC | ||
- | | Shellinabox | ||
- | | DemoServer | ||
- | | Technikserver | ||
- | |||
- | ==DNS-Vorbereitungen== | ||
- | * Dyn-DNS-Adresse besorgen / festlegen (z.B. gatewayexample.dynv6.net) | ||
- | * Zieladressen der Server per CNAME auf die Dyn-DNA-Adresse lenken | ||
- | |||
- | ==OPNsense: Installation und erste Konfiguration== | ||
- | Stand: April 2020 | ||
- | * Konfigurieren der virtuellen Netze | ||
- | * OPNsense installieren als FreeBSD 11.2 auf KVM, | ||
- | * dabei virtuellen Netzwerkkarten schon vorher als virtio mit den entsprechenden Netzen verbinden. MAC-Adressen merken... | ||
- | * ich empfehle auf Englisch mit Deutscher Tastatur zu arbeiten. | ||
- | * Nach der Installation die Netzwerkschnittstellen inkl. DHCP konfigurieren (nicht Teil dieser Anleitung). | ||
- | * System-> | ||
- | * TCP port: 4433 (**Unbedingt** den Port (Standard: 443) verlegen - z.B. auf 4433.) | ||
- | * HTTP Redirect: ✓ (**Unbedingt** Haken setzen für Disable web GUI redirect rule) | ||
- | * Save (nun im Browser die neue Adresse aufrufen und Lesezeichen setzen) | ||
- | * Services -> Dynamic DNS für z.B. Dynv6.com konfigurieren, | ||
- | * System -> Settings -> Cron dort " | ||
- | * enable: ja, | ||
- | * Minutes: eine Zahl<60 | ||
- | * Hours: z.B. 4,6,12,18 | ||
- | * Command: Dynamic DNS Updates | ||
- | * Description: | ||
- | * Save | ||
- | * Apply | ||
- | * Jetzt sollte die Firewall die Server anpingen können und die IP-Adresse beim Dyn-DNS-Dienstleister aktualisieren. Testen! Morgen noch einmal testen! | ||
- | |||
- | ==Fritzbox== | ||
- | * OPNsense für Freigaben auswählen | ||
- | * Port-Forwarding (http, https) und Ping6-Freigabe einrichten | ||
- | * noch nicht testbar... | ||
- | |||
- | |||
- | ==OPNsense: Software nachinstallieren== | ||
- | * System -> Firmware -> Plugins: | ||
- | * os-haproxy | ||
- | * os-acme-client | ||
- | |||
- | |||
- | |||
- | |||
- | ===Konfiguration von Letsencrypt (acme-client) und von HAProxy=== | ||
- | Es gibt es einige ausführliche Anleitungen - siehe am Ende der Seite unter Quellen. Meist sind es aber "klick dies - tipp das" | ||
- | Damit man weiß, was man überhaupt konfiguriert, | ||
- | |||
- | {{: | ||
- | |||
- | * Ein einkommender Request (Anfrage eines Browsers) muss zuerst die Firewall von OPNsense überwinden, | ||
- | * Der Request wird von einem der konfigurierten // | ||
- | * Hier gibt es jeweils einen für Port 80 (HTTP) und Port 443 (HTTPS). | ||
- | * Der HTTPS-Public-Service arbeitet mit aktiviertem " | ||
- | * Jeder Public-Service enthält //Rules//, die zum Entscheiden auf // | ||
- | * Typisch: | ||
- | * Condition url_ist_shellinabox prüft, ob der angefragte Host den Namen für den shellinabox-Server hat. | ||
- | * Rule server_shellinabox hängt von obiger Condition ab und leitet den Request bei " | ||
- | * Viele Regeln steuern nun den Zugriff auf einen Backend-Pool, | ||
- | * Die Idee ist, dass man die Arbeit auf mehrere identische Server verteilen kann inkl. Ausfallsicherheit. Dann kann man sie der Reihe nach neu starten, ohne dass der Kunde eine Unterbrechung merkt. Daher das HA im Namen... | ||
- | * Der echte Server bekommt nun über das Netzwerk den Request und gibt eine Antwort zurück, die zum Client weitergeleitet wird. Im Falle von SSL-Offloading wird die Antwort natürlich verschlüsselt weitergeleitet (ohne dass der echte Server dies tut). | ||
- | * Ein spezieller Real-Server ist der vom Letsencrypt-Plugin eingerichtete acme_challenge_host, | ||
- | * Die Verschlüsselung beim Public-Service greift auf das von Letsencrypt gelieferte Zertifikat zurück - sobald es da ist. Man kann den Public-Service für Port 443 also erst danach aktivieren! | ||
- | |||
- | Unnötig zu sagen, dass HAProxy natürlich deutlich komplexer ist, als hier dargestellt... | ||
- | |||
- | ===Quellen & Links=== | ||
- | Deutsche Anleitung: | ||
- | |||
- | Englische Anleitung: | ||
- | |||
- | Mozilla SSL-Konfiguration: |