VPN Server lokal Zuhause auf Raspi 3 oder im RZ auf einem VPS nano?

Zitat von Hille

VPS B Ostern 2017

ja der ist ausch schön mit seinen 100GB Festplattenplatz

Zitat von Borgqueen

Besteht die Möglichkeit das Monitoring (Web-Admin-Oberfläche) per nur per ssh Tunner per einer lokalen IP aufzurufen wenn ich es benötige.
Und dass ansonsten der Zugang (Web-Admin-Oberfläche), wenn der ssh Tunner nicht aufgebaut ist, dann auch nicht erreichbar ist?

Das geht beispielsweise dadurch, dass Du checkmk in einem Container installierst (vorzugsweise einen System-Container via Incus/LXD anstelle eines Anwendungs-Containers via Docker/Podman); durch das Mapping der Ports kannst Du sicherstellen, dass ohne jegliche Änderung der Standardeinstellung der Anwendung (hier: checkmk) von "außen" (also dem Hostrechner) nur ein Zugriff via 127.0.0.1 möglich ist. Diese Abschirmung ist insofern wasserdicht, als sie von der Anwendung im Container nicht modifiziert werden kann.

Analog ist es natürlich möglich, via iptables/nftables durch Regeln den Zugriff auf den checkmk-Port (bzw. die zugehörige Web-Admin-Oberfläche, also den Apache-Port) einfach auf 127.0.0.1 zu beschränken (wenn sich die checkmk-Apache-Instanz mit dem anderen Apache2 direkt auf dem Host "verträgt"). Tip: Diese Regeln lassen sich nach Einrichtung "persistieren", so dass sie sofort nach Initialisierung des Netzwerks im Rahmen des Bootvorgangs gültig werden – bevor irgendeine Anwendung gestartet wird. Dadurch ist sichergestellt, dass checkmk nicht temporär von außen erreichbar wäre, bis die Regeln anderweitig gesetzt werden.

Mir ist dein Konstrukt nicht so ganz klar. Hast du Checkmk lokal zu laufen? Wenn ja, ist der Zugriff dann eingehend ebenfalls nur lokal?

Zitat von Borgqueen

m_ueberall

Danke für die Lösungsansätze.

Aktuell habe ich Checkmk normal ohne Docker etc installiert. Die Datenverbindungen zwischen Agent und Server sind secure.

Aber dass man von außen an */monitoring/ an die Login-Seite gelangt ist mir nicht so wohl dabei.

Daher habe ich aktuell omd temporär deaktiviert.

Funktioniert es in meinem Fall der Installation (wie ich Checkmk aufgesetzt habe) wenn man dies über via iptables/nftables löst?

Alles anzeigen

Ich selbst verwende Checkmk nicht; auf Basis der Installationsbeschreibung hier ist die Lösung tatsächlich noch einfacher, wenn Checkmk den "system-apache" als Reverse Proxy (auf Ports 80/443) verwendet, während der "site-apache" auf Port 5000 läuft.

Um diese Annahmen zu verifizieren, kann man als root nach Starten aller Apache-Instanzen auf der Konsole ein "LANG=C netstat -tulpen | grep -E '^[AP]|:5000'" eingeben (Abfrage, auf welche IP-Adressen/Ports der "site-apache" reagiert; "netstat" kann man via "apt-get -y install net-tools" installieren, wenn nicht vorhanden).

(1) Wenn der vorherige Befehl sowas zurückliefert wie "tcp […] 0.0.0.0:5000" bzw. "tcp6 […] :::5000", dann lauscht/reagiert der site-apache auch auf Abfragen von außen über die offizielle IP-Adresse. Das sollte man unterbinden – vorzugsweise über eine Konfigurationsänderung auf dem Host/Raspi selbst.

(2) Daneben ist zu beachten, dass der Reverse Proxy (der "system-apache" im referenzierten Post) grundsätzlich auch auf allen IP-Adressen lauscht und auf externe Abfragen antworten würde – selbst wenn man den "site-apache" oben auf localhost einschränken würde (wenn das nicht schon der Fall ist), darf/muss der Zugriff über den "system-apache" (zwangsweise) immer auch via 127.0.0.1 erfolgen (die alleinige Absicherung vom "site-apache", den Checkmk mitbringt, würde beim Zugriff über den Reverse Proxy/system-apache also immer "unterlaufen" werden). Ergo muss man auch die von "system-apache" gelesenen Konfigurationen, die checkmk mitbringt, insofern ändern, dass hier nur ein lokaler Zugriff möglich ist.

^ ^ Einschub: Nach Lesen obiger Konfiguration scheidet die iptables/nftables-Lösung dann aus, wenn Teile des "system-apache" (also andere auszuliefernden Seiten) immer verfügbar sein sollen und nur "*/monitoring/" lediglich lokal ausgeliefert werden soll – denn hier muss die Filterung/Zugriffssteuerung auf Apache-Ebene (Applikationsebene) erfolgen – iptables/nftables bzw. eine Einschränkung der IP-Adressen, auf welche der system-apache hört, läuft nur auf TCP/IP-Ebene.

(2b) Soll der "system-apache" und der "site-apache" vollständig nur lokal verfügbar sein (kein Problem, wenn man von außen zuvor via ssh auf den lokalen Rechner wechselt), dann empfiehlt sich für beide Instanzen eine Einstellung in /etc/apache2/ports.conf (für den "system-apache" -- keine Ahnung, wo der "site-apache" seine Konfiguration ablegt, nicht nachgeschlagen):

#Statt der Namen unten, die vom DNS-Server aufgelöst werden können müssen (wäre ggf. einzutragen!), kann man direkt "127.0.0.1" bzw. "::1" verwenden – hier nur zur Verdeutlichung, was man haben will:
Listen ip4-localhost:80
Listen ip4-localhost:443
Listen ip6-localhost:80
Listen ip6-localhost:443

(Alle anderen "Listen"-Direktiven sind natürlich aus der Datei "ports.conf" zu entfernen; nach Neustart der jeweiligen Apache-Instanz kann wieder "netstat -tulpen | grep -E ':80|:443|:5000'" zur Überprüfung herangezogen werden, wo es jetzt keine "0.0.0.0"- bzw. ":::"-Einträge mehr geben darf.)

(2c) Wenn man nicht darauf vertraut, dass obige Einstellungen Bestand haben nach Veränderung der Konfigurationsdateien, kann man zusätzlich via iptables/nftables die entsprechenden Ports 80, 443 (system-apache) und 5000 (site-apache) ggü. Zugriffen von anderen IP-Adressen blockieren. Hier ist aber zusätzlich zu beachten, dass man normalerweise daheim irgendeine Fritz-Box o.ä. vom Internet-Provider vor dem internen lokalen Netzwerk hat, und auch hier müsste man überhaupt explizit einmal die entsprechenden Ports (nur 80, 443) freischalten.

(2d) Zur Einschränkung auf Apache2/Anwendungsebene: In den von Checkmk eingebundenen Regeln sollte sich ein Konstrukt ähnlich dem Folgenden für den "Reverse Proxy" (system-apache) finden ("ähnlich" insofern, als dass irgendwo eine "Directory"-Definition stehen muss, die den Zugriff regelt – das unten ist keine Reverse-Proxy-Definition, die wäre länger; alternativ könnte ggf. auch eine "Location"-Definition zur Anwendung kommen):

<Directory /blahblubb/monitoring/>
    DirectoryIndex index.php
    Options -Indexes +FollowSymLinks
    AllowOverride FileInfo Options
    Require ip 192.168.0.0/16 172.16.0.0/16 10.0.0.0/8 127.0.0.1 ::1
</Directory>

Hier ist lediglich die letzte Zeile zu ergänzen – diese regelt, dass Apache alles unterhalb von /blahblubb/monitoring/ nur dann ausliefert, wenn die Anfrage (an den system-apache/Reverse Proxy über Port 80/443) von einer lokalen IP-Adresse kommt.

Die von Hille eingangs vorgeschlagene Lösung, checkmk auf einer lokalen IP-Adresse wie z. B. 10.0.0.10 laufen zu lassen und dann per VPN darauf zuzugreifen, sollte ja auch möglich sein.

Dazu müsste der checkma-Apache auf der lokalen IP-Adresse lauschen und die Adresse dem WireGuard-Interface zugewiesen werden (falls Du WireGuard nimmst). Auf den Client-Rechnern müsste dann entsprechend die VPN-Verbindung eingerichtet und in der netcup-Firewall das VPN freigeschaltet werden.

Der checkmk-Apache könnte dabei auf Port 80 laufen.

EDIT: Nach Lesen des von m_ueberall verlinkten Beitrags, gilt auch hier vermutlich, dass man verhindern muss, dass der System-Apache als Reverse Proxy für Checkmk fungiert und die Monitoring-Seite öffentlich zugänglich macht. Evtl. kann man in der erwähnten Datei zzz_omd.conf den Include-Eintrag auskommentieren? Da sollte man dann bei einem Checkmk-Update sicherheitshalber prüfen, ob er wieder aktiviert wurde.

Wenn Du statt des VPN-Tunnels einen SSH-Tunnel verwenden möchtest, solltest Du Checkmk ja einfach mit ssh -L 5000:127.0.0.1:5000 user@nano über http://localhost:5000 aufrufen können, wenn das die Standardeinstellungen des Checkmk-Apaches sind. Die Tunnelkonfiguration würde ich dann in die .ssh/config auf dem Client eintragen.

Zitat von Borgqueen

Hallo zusammen,

würdet Ihr, wenn Ihr einen VPN Server einsetzen wollt, diesen eher auf einem Raspi 3 Zuhause oder auf einem VPS nano im RZ betreiben?

Mein Anliegen

Ich möchte für den Einsatz von Monitoring einen VPN Server aufsetzen. So dass der Austausch der Montitoring-Daten und auch das Montoring grafisch betrachten über eine lokale IP per VPN stattfindet.

Beim Monitoring bin ich aktuell noch am überlegen ob ich checkmk oder Munin verwende. Hatte beides schon Mal im EInsatz.

Bei der Lösung einen Raspi 3 dafür einzusetzen habe ich bedenken weil dieser ja nur eine 100er Netwerkkarten Anbindung hat. Ich will da ungern einen Flaschenhals produzieren.

P.S habe weitere Server im RZ für die primär das Monitoring stattfinden soll.

Wie würdet Ihr in meinem Fall dies lösen?

Alles anzeigen

Ich setze als Monitoring Loesung Centreon ein, bei Netcup laeuft nur der Backup-MX sowie ein Webserver (u. a. fuer mta-sts und letsencrypt). Der Monitoring Server verbindet sich ueber NRPE 4.0 (TCP/5666 mit TLS 1.2) zu den beiden Netcup VPS, also kein VPN. Da die meisten Server (>15 )bei mir lokal laufen, kommen zwei Protectli 6-Port zum Einsatz mit Proxmox als Hypervisor, Sophos XG (Active-Passive) als Firewall und Grommunio als Mailserver. Die Protectli laesst sich ganz klein skalieren fuer deine Zwecke und gibt es auch mit 2 Ports oder 4 Ports. Vor zwei Jahren habe ich begonnen, fast alles lokal laufen zu lassen, auf Grund der jaehrlich steigenden Kosten fuer Webhosting. Ein Business Anschluss mit statischer IP ist unterm Strich einfach guenstiger.

Zitat von ckd

Vor zwei Jahren habe ich begonnen, fast alles lokal laufen zu lassen, auf Grund der jaehrlich steigenden Kosten fuer Webhosting. Ein Business Anschluss mit statischer IP ist unterm Strich einfach guenstiger.

Auch wenn du die Stromkosten für den 24/7/365 betrieb mitrechnest?

Was ist mit Ersatzhardware und Investition?

Zitat von ASS

Auch wenn du die Stromkosten für den 24/7/365 betrieb mitrechnest?

Was ist mit Ersatzhardware und Investition?

Es sind mehr als 15 VMs: Firewall Active-Passive, Monitoringserver, Mailserver, zwei Backupserver, interne CA, ein OpenCloud, ein Windows Server fuer die Steuererklaerung der einmal im Jahr nur zu diesem Anlass hochgefahren wird, der Rest sind Webserver / Webseiten und ein paar Testinstanzen. Alles Debian 12 / Debian 13 inklusive Hypervisor.

Die Snapshots werden taeglich gesichert, d. h. Restorezeiten sind gering und wenn eine der beiden Kisten kaputt geht, wird die vorinstallierte Ersatzhardware aus dem Schrank gezogen und hochgefahren. In der Zeit bin ich halt teilweise oder ganz offline und der Backup-MX (1 EUR pro Monat) bei Netcup sorgt dafuer, dass keine Mails verloren gehen.

Stromverbrauch liegt zwischen 12 Watt (idle) und maximal 100 Watt (lt. Datenblatt), laut Messungen aber im Durchschnitt bei 30 Watt, der Strompreis bei 23 Cent pro kwh und somit bei zirka 60 EUR pro Jahr (mal zwei). Die Lebenserwartung der Protectli liegt bei locker fuenf Jahren und wenn man Pech hat, muss man in der Zeit vielleicht mal eine Festplatte tauschen oder das externe Netzteil ersetzen oder vielleicht auch mal einen RAM-Riegel, wenn Murphy einen langweilen moechte.

Zudem moechte ich zu Hause nicht auf die Vorzuege einer Hardware-Firewall (Sophos XG Home) verzichten mit sauber getrennten Netzen und WiFi (4 x SSID VLANs) fuer zwei Wohneinheiten verteilt ueber drei Stockwerke + ich bin flexibel, wenn ich temporaere VMs brauche um etwas zu testen und da sowieso nur noch Linux zum Einsatz kommt, habe ich nichts, was irgendwie hohe Hardwareanforderungen haette.

Auf fuenf Jahre (2 x Hardware + 1 x Ersatzhardware + Stromverbrauch 5 Jahre + 1 x Ersatzplatte + 1 x Ersatznetzteil) gerechnet und dann auf den Monat runtergebrochen, liegen die Unterhaltungskosten bei gerade mal ~60 EUR im Monat. Als Rechenbeispiel und dann auch wirklich grosszuegig aufgerundet: 2000 EUR + 1000 EUR + 600 EUR + 60 EUR + 20 EUR / 60 Monate = 61,33 EUR

Es steht und faellt jedoch alles mit falschen Design- oder Produktentscheidungen. Mit Windows Betriebssystemen im Mischbetrieb geht das Konzept schonmal nicht auf, das schafft zum einen die Hardware nicht und zum anderen geht dann der Stromverbrauch durch die Decke.

Sind die Kenntnisse zum Betrieb einer Mailinfrastruktur und tiefe Firewallkenntnisse nicht vorhanden, dann hat man auch ein Problem. Ist nicht ausreichend Bandbreite vorhanden oder keine statische IP moeglich, dann kann man einpacken. Man sollte halt schon wissen, was man tut, wenn man sowas in Eigenregie hochzieht. Keines der Linuxserver hat eine GUI, es wird alles auf der Shell gemacht. Alles ist automatisiert und im Monitoring.

Wenn man dann noch in der Branche und fast ausschliesslich von zu Hause aus arbeitet, kann man einen Teil davon noch von der Steuer absetzen, inklusive des eigenen Internetanschlusses (Business mit statischer IP). Also ja, es rechnet sich definitiv.

Eine weitere Lösung könnte evtl Pangolin sein, wenn das nicht schon genannt wurde

Zitat von Borgqueen

Dann aber per Docker.

now thats a slippery slope - good luck sailor.

Zitat von webdesignheld

now thats a slippery slope - good luck sailor.

Unqualifizierter Kommentar von dir...

Also: was willst du damit sagen?

checkmk in Docker läuft grandios. Ich selbst betreibe die checkmk Cloud Edition schon paar Jahre hier auf Docker.

Und ja, ich betreibe checkmk auch bei mir in der Firma, bisschen größer als in meinem Privaten Lab. Da, aufgrund einer alten Designentscheidung allerdings leider direkt installiert. Will ich aber auch noch zu docker migrieren.