LogoDIDACT-Dienste freigeben

Der Reverse-Proxy ermöglicht einen einfachen und sicheren Zugriff über das Internet von außen auf die vielen lokalen Web-Dienste des LogoDIDACT-Servers. Durch den Einsatz eines Proxys wird im Zuge dessen die Sicherheit erhöht, da die interne Struktur des Servers verborgen bleibt.

Vorbereitungen und Voraussetzungen

Damit die Auflösung über DNS von extern auf den korrekten internen Dienst funktioniert müssen einige Voraussetzungen erfüllt sein:

eine gültige Internet-Domain, welche auf die öffentliche IP des LD-Servers auflöst.
der Proxy-Forwarder auf dem ldhost ist aktiviert
in der Shorewall des ldhost und auf dem vorgeschalteten Router sind die Ports HTTP(80) und HTTPS(443) freigegeben
die Zertifikatsverwaltung Let's Encrypt ist aktiviert oder es werden eigene Zertifikate für die Absicherung der Webdienste bereitgestellt

Internet-Domain

Definiert ist diese im puppeteer-g3 in der Datei internet.domain. Standardmäßig ist das die Adresse schulkuerzel.logoip.de. Die im logosrv per ldipupdate gesetzte shortname.logoip.de-Adresse muss hierbei übereinstimmen, sofern diese verwendet wird.

Bei Nutzung einer eigenen Internet-Domain stellen Sie sicher, dass in der DNS-Verwaltung der gehosteten Domain die DNS-Einträge für die LD-Dienste auf den LD-Server verweisen.

Proxy-Forwarder aktivieren

Damit die Auflösung und Weiterleitung interner LogoDIDACT-Dienste aus dem Internet reibungslos funktioniert, wird auf dem ldhost ein Proxy-Helper-Service aktiviert. Dieser dient dazu Anfragen aus dem Internet auf der externen Schnittstelle des LD-Servers entgegenzunehmen und diese an den internen Container rproxy-ext weiterzuleiten.

Info

Die Konfigurationsanpassung findet man im puppeteer-g3 unter man components.forwarder.

Dazu in den Container puppeteer-g3 verbinden und die Datei ldhost.yaml ergänzen.

root@puppeteer-g3:~ # vi /etc/logodidact/hiera/custom.d/ldhost.yaml

ldhost.yaml
ld_base::components: {forwarder: true}

Dadurch wird die Software HAProxy als Application-Proxy im ldhost hinzugefügt. Dies wird durch einen anschließenden prun dort ausgelöst. Die Anpassung wie gewohnt ins GIT commiten.

Shorewall Anpassungen

Damit die Anfragen aus dem Internet überhaupt entgegengenommen und verarbeitet werden können, müssen die entsprechenden Zugriffe und Weiterleitungen in der Firewall auf dem ldhost freigeschaltet werden.

root@ldhost:~ # vi /etc/shorewall/rules

rules
1 2	`HTTP(ACCEPT) ext $FW HTTPS(ACCEPT) ext $FW`

Nun die Shorewall auf Syntax-Fehler prüfen und neu starten.

1 2	`root@ldhost:~ # shorewall check root@ldhost:~ # shorewall restart`

Let's Encrypt Zertifikatsverwaltung

Natürlich benötigen die LogoDIDACT-Webdienste Zertifikate zur Absicherung der Verbindung. Wie Sie dies realisieren ist in diesem Artikel beschrieben: Zertifikatsverwaltung

Dienst freigeben

Die Freischaltung eines LD-Dienstes erfolgt in der sog. rproxy-int.yaml (Freischaltungen im lokalen internen Netzwerk) bzw. rproxy-ext.yaml (Freischaltungen aus dem Internet) im Logodidact-Konfigurationsverzeichnis im puppeteer-g3.

Info

Die allermeisten vom LD-Server gehosteten Dienste sind bereits automatisch für das interne Netzwerk freigeschaltet.

Im nachfolgenden Abschnitt wird beispielsweise die Nextcloud inklusive der quelloffenen collaborativen Office-Plattform Collabora freigeschaltet.

root@puppeteer-g3:~ # vi /etc/logodidact/hiera/custom.d/rproxy-ext.yaml

rproxy-ext.yaml
ld_rproxy2::access:
  - nextcloud-g2
  - collabora

Wichtig ist dabei zu beachten, dass der freizuschaltende Dienstname dem zugrundeliegenden Containernamen entspricht. Beispielsweise wird bei der Nextcloud der Name nextcloud-g2 verwendet.

Wie gewohnt die Änderung in GIT commiten und einen prun im Container rproxy-ext durchführen.

Weiterleitung einer URL

Es lassen sich auch Adressen weiterleiten bzw. tunneln, sodass ein LD-Dienst über eine alternative Adresse erreichbar ist.

Hier im Beispiel wird die Adresse files.shortname.logoip.de an die Adresse nextcloud-g2.shortname.logoip.de weitergeleitet.

Das Feld domain steht für den Alias und setzt sich aus dem neuen Namen und der globalen Variable für die Internet-Domain des LD-Servers zusammen.

access betitelt den Namen der Freigabe und muss dem Wert unterhalb ld_rproxy2::proxied entsprechen.

kind beschreibt die Art und Weise wie der Proxy die Anfrage weiterverarbeiten soll.

data ist das Ziel, wohin der Rev-Proxy die Anfrage weiterleiten soll.

Info

Weiterführende Informationen finden sich in der manpage unter man role.rev-proxy.

Der vergebene Freigabe-Name, hier redirect-cloud wird schlussendlich verknüpft im Feld ld_rproxy2::access: []. Erst dadurch wird die Adresse vom Rev-Proxy verwendet und freigeschaltet.

rproxy-ext.yaml
ld_rproxy2::access: [..., redirect-cloud]

ld_rproxy2::proxied:
 redirect-cloud:
   domain: "files.%{enc.zones.internet.domain}"
   access: redirect-cloud
   kind: redirect
   data: "https://nextcloud-g2.%{enc.zones.internet.domain}"

Tipp

Es wird empfohlen für die alternative URL ein signiertes Zertifikat, beispielsweise über Let's Encrypt, bereitzustellen.

lokalen Web-Dienst freischalten

Im Beispiel wird ein Webserver, der auf einer zusätzlichen KVM "Klabusrv" auf dem ldhost läuft, von extern freigegeben. Die Datei /etc/logodidact/hiera/custom.d/rproxy-ext.yaml im puppeteer-g3 um folgenden Inhalt erweitern:

rproxy-ext.yaml
ld_rproxy2::access: [..., klabu]

ld_rproxy2::proxied:
  klabu:
    data: {cond: "true", bk: bk_http, ip: "10.16.1.2", proxy_mode: 'http', port: 443, proxy_port: 80}
    domain: "klabu.%{enc.zones.internet.domain}"
    kind: proxy

Tipp

Es ist auch möglich, anstatt der rproxy-ext.yaml eine allgemeingültige rev-proxy.yaml zu erstellen. Diese muss man allerdings mit demselben Inhalt im Verzeichnis /etc/logodidact/hiera/custom.d/role.d/ abspeichern. Bei Verwendung der allgemeingültigen rev-proxy.yaml schaltet man die Dienste sowohl für den Zugriff vom lokalen Netzwerk als auch im Internet parallel frei. Dies ist üblicherweise bei Webdiensten sinnvoll.