5 Min. Lesezeit

Incus und Dienste freigeben

Nachdem man jetzt Incus installiert hat und Container und virtuelle Maschinen erzeugen kann, die in ihrem eigenen Netzwerk miteinander kommunzieren können und auch Zugriff auf Internetresourcen haben, möchte man vielleicht auch einige Dienste (nextcloud z.Bsp.) allgemein verfügbar machen. Dazu gibt es mehrere Methoden, die unterschiedliche Aspekte bzgl. Zugriffsicherheit aufzeigen.

Man muss sich immer bewußt sein, das man mit einem Dienst, den man für das Internet freigibt, immer ein Risiko eingeht ... jeder Dienst wird fürher oder später (eher früher) auch von den Bösen besucht, und die versuchen, eine Schwachstelle zu finden und auszunutzen.

Als Beispiel möchte ich hier meine Geschichte mit meinem Emailserver erzählen, ich betreibe schon seit über 20 Jahren eigene Emailserver und denke eigentlich, ich weiß, was ich da tue. Aber auch mir passiert durch die viele Spielerei mal ein Lapsus ... im konkreten Fall hatte ich die Portfreigaben im Incus nicht wirklich verstanden und habe kurzfristig einen offenen Relay ins Internet gestellt (deswegen werde ich zeitnah auch noch mal einen Post über Portfreigaben im incus machen), der auch prompt ausgenutzt wurde. Es hat keinen Tag gedauert, da hatten irgendwelche Spammer das entdeckt und haben fröhlich Spams verteilt über meinen Server. Als die ersten Postmastermails an mich kamen mit "Hey, dein Server verschickt massenhaft Spams ...", habe ich zuerst ungläubig und dann panisch reagiert, erst mal alles abgestöpselt und analysiert und ja, es war mein Konfigurationsfehler. Ich hätte mich eingehender damit beschäftigen müssen und es tut mir bis heute leid.

Das nur als Warnung, jeden Dienst, den man ins Internet stellt, sollte man verstanden haben und auch ziemlich genau wissen, wie und warum der was tut. Bitte nicht nur Anleitungen aus dem Internet kopieren, ohne sich damit zu beschäftigen.

Soviel zum Vorwort, jetzt aber mal die von mir genutzten Methoden.

  1. Portfreigaben

Wie schon oben erwähnt, gibt es die berühmten Portfreigaben. Die gibt es auch im Router, wenn man z.B. eine Fritzbox hat, kann man Sachen aus dem Homenetz freigeben. So habe ich auch angefangen und Sachen von meinem Rasbpi ins Internet gestellt.

Spätestens beim besagten obigen Emailserver ist es mit einem Rasbpi im Homenetz aber nicht mehr so einfach, so begann auch meine Reise in die Welt der VPS Server und alles weitere. Am Ende bin ich dann bei Incus gelandet (vorher Proxmox) und da laufen dann alle Dienste in einem eigenen Netz und müssen von da noch freigegeben werden.

Bei docker ist es die Option -p .... damit kann man die intern laufenden Dienste für den Host freigeben.

Im incus nutzt man hierfür die proxy-Direktive:

incus config device add <instance_name> <device_name> proxy listen=<type>:<addr>:<port>[-<port>][,<port>] connect=<type>:<addr>:<port> bind=<host/instance>

Mal ein Beispiel, gesetzt den Fall, man betreibt eine nextcloud Instanz, die intern auf 8443 horcht und möchte, das die am Host über den Standardport 443 erreichbar ist, könnte die Freigabe wie folgt aussehen:

incus config device add nextcloud port443proxy proxy connext=tcp:127.0.0.1:8443 listen=tcp:0.0.0.0:443

Soweit erst mal hier, über Freigaben und Incus mache ich noch einen gesonderten Beitrag

  1. Reverse Proxy

Mit den Freigaben kommt man solange klar, bis man verschiedene Dienste hat, die alle die Standarports 80 und/oder 443 nutzen wollen. Die meisten kann man zwar umkonfigurieren, aber man möchte nicht immer unbedingt Portnummern mit eintippen müssen, wenn man den Dienst aus dem Internet nutzt.

Hier kommt der Reverse Proxy ins Spiel. Der horcht auf 80 und 443 verteilt dann die Anfragen an die Incusinstanzen.

Ich habe hier zuerst traefik benutzt und bin dann auf caddy gestossen und bei caddy bin ich geblieben, weil es so eine einfache Syntax hat. Beide, treafik und caddy, machen Zertifikatsanfragen bei letsencrypt automatisch, man muss sich also nicht selbst etwas basteln, um die Zertifikate rechtzeitig zu erneuern, das machen die Proxies für einen. Nginx und Apache sollten nicht unerwähnt bleiben, die können natürlich auch reverse proxy, allerdings muss man sich hier dann selbst um Zertifikate kümmern.

Also caddy, im meinem ersten Post hier habe ich schon mal erklärt, wie ich Ghost als Blogsoftware installiert habe und da habe ich auch caddy erwähnt.

Caddy läuft als incus container mit den Portfreigaben für 80 und 443 und wird im wesentlichen konfiguriert über die Datei /etc/caddy/Caddyfile. Die Syntax ist wirklich einfach und ziemlich selbsterklärend, ich gebe euch hier mal einen Auszug meines gerade aktuellen Caddyfiles

blog.frischux.de {
        reverse_proxy ghost.incus:2368
}

ntfy.frischux.de {
        reverse_proxy ntfy.incus:8080
}

vw.frischux.de {
        reverse_proxy vaultwarden.incus:8000
}

paperless.frischux.de {
        reverse_proxy paperless.incus:8000
}

nc.frischux.de {
        reverse_proxy nextcloud.incus:80
}

dawarich.frischux.de {
        reverse_proxy dawarich.incus:3000
}

fotos.frischux.de {
        reverse_proxy immich.incus:2283
}

Das Beispiel zeigt schön das Zusammenspiel von caddy und dem incus internen Netzwerk, das löst für mich die internen Adressen auf, ich muss nicht wissen, auf welcher IP-Adresse gerade mein paperless-Archiv läuft, ich nutze einfach den Container-/Maschinennamen.

Caddy ist super, ich bin aber gerade auf der Migration zu einer (für mich) noch schöneren Lösung und die kommt jetzt.

  1. Pangolin/Newt

Mit caddy hat man ja immer noch die Portfreigabe an der Backe, d.h. man muss den Internetverkehr aktiv irgendwo hinleiten auf seinem Server. Das mag auf einem VPS, der direkt am Internet hängt, einfach sein. Komplizierter wird es, wenn (wie bei mir zuhause) ein Server hinter 2 Routern hängt, also erst eine Fritzbox und dahinter dann ein OpenWRT-Router. Dann wird es schon komplexer, den Internetverkehr dort durchzuleiten.

Hier kommt Pangolin ins Spiel, Pangolin macht eine getunnelte VPN-Verbindung zum Server auf (bzw. andesherum, der Server zum Pangolin) und leitet den ganzen Netzwerkverkehr da durch. Wenn man sowieso schon ein VPN betreibt, kann man mit Pangolin auch das nutzen. Praktisch ist aber das kleine Tool newt .... das kann man auch in einem Incuscontainer starten, das sorgt dann dafür, daß praktisch alle Server, die sich im gleichen Incusnetzwerk befinden, sich mit dem Pangolinserver über die getunnelte Verbindung unterhalten können.

Der Pangolinserver kann irgendwo im Internet stehen ... ich habe z.B. einen 1€ Server von Ionons oder Strato genommen, den Pangolin darauf installiert, das reicht völlig aus, die Kiste langweilt sich zu Tode. Natürlich kann man Pangolin auch als Incusinstanz aufsetzen, wenn man jetzt schon einen VPS hat und keinen zweiten Server dazumieten möchte. Wichtig ist nur, das der Pangolinserver direkt im Internet hängt.

Da muss man dann natürlich wieder 80 und 443 für Pangolin freigeben, aber das ist ja dann auf dem isolierten Server, wenn da jemand einbricht und marodiert, ist mein eigentlicher Server und meine wichtigen Dienste und Daten nicht betroffen. Einfach newt ausknipsen und schon kann nichts mehr passieren. Ich finde das geradezu genial.

Nochmal, auf dem Server, auf dem man seine Dienste betreibt, benötigt man keinerlei Portfreigabe (okay, eine Ausnahme gibt es, Email bekommt man so nicht einfach geroutet, das ist aber eine andere Geschichte), es reicht ein newt container, der im incus Netzwerk, dass man freigeben will, hängt. Die konkreten Freigaben macht man dann im Pangolinwebinterface.

An Pangolin kann man mehrere newt-Instanzen anbinden, so kann man auch schön seine Dienste zentral verteilen und umziehen, ohne den externen Zugriff darauf ändern zu müssen. Meinen Vaultwardenpassortcontainer z.Bsp. kann ich also wahlweise zuhause laufen lassen, aber auch im VPS beim Provider, der Zugriff geschieht immer über die gleiche URL. die habe ich überall eingerichtet und habe somit immer und überall Zugriff auf meine Passwörter, egal wo der Dienst nun letztendlich läuft, umschalten passiert im Pangolinwebinterface mit einem Klick.

Patrick Frisch