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 18:14] – [Fehler, die mir unterkamen und ihre Ursachen] 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 passenden Backend-Pool, | ||
- | * Die Idee ist, dass man die Arbeit auf mehrere identische Server verteilen kann inkl. Ausfallsicherheit. | ||
- | * Dann kann man sie z.B. 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. auch Backend-Server können Regeln haben. Benutzeranmeldung kann gemacht werden... | ||
- | |||
- | ===Fehler, die mir unterkamen und ihre Ursachen=== | ||
- | * Letsencrypt kann das Zertifikat nicht aktualisieren | ||
- | * -> überprüfe, | ||
- | * -> findet für diese URL eine Weiterleitung zu https statt, so ist entweder | ||
- | * eine solche im HAProxy eingerichtet worden (dann ergänze die Rule so, dass beim acme-challenge-Verfahren nicht weitergeleitet wird) oder | ||
- | * oben der Haken bei " | ||
- | * HAProxy lässt sich nicht starten | ||
- | * -> Teste die Konfiguration mit dem Button | ||
- | * -> Sind bei abgeschaltetem HAProxy die Ports 80 und 443 wirklich frei? D.h. nicht erreichbar? | ||
- | * Übrigens: Wenn fälschlicherweise immer noch die Administration auf 443 läuft, so bekommt man auch eine merkwürdige DNS-Rebind-Attack-Meldung. Daher " | ||
- | * Die Server sind aus dem LAN zwischen Fritzbox und OPNsense nicht zu erreichen. | ||
- | * Private Network Adresses für WAN-Interface gesperrt? (OPNsense-WAN-Interface-Konfiguration) | ||
- | * Namensauflösung gescheitert, | ||
- | ===Quellen & Links=== | ||
- | Deutsche Anleitungen: | ||
- | * Schulnetzkonzept: | ||
- | * Triumvirat: [[https:// | ||
- | |||
- | Englische Anleitung: | ||
- | * OPBsense-Forum: | ||
- | * | ||
- | |||
- | Mozilla SSL-Konfiguration: | ||
- | * [[https:// |