Infrastructure Review 2018-06-06

Beitrag vom 05.06.2018

Im netcup Kunden Forum kam die Frage auf, wie ich meine vServer in mein Heimnetz eingebunden habe. Da ich ja hier auch schon über meine Spielestreaming Box, das ZFS Setup und mein IoT Setup berichtet habe, die Antwot gleich als Blogpost.

+-----+  +-----+
| VM1 |  | VM2 |
+---+-+  +--+--+
    |       |
+---+-------+------+   +----------------+
| netcup vServer   +---+ DNS            |
| Proxmox, OpenVPN |   | Proxmox Guests |
+--------+---------+   +----------------+
         |
         |
+--------+---------+    +----------+
| OpnSense Router  |    | Notebook +---+
| VLANs, Firewall, |    +----------+   |
| OpenVPN          |    +----------+   |
+-------+----------+  +-+ Unifi AP +---+
        |             | +----------+
+-------+-------+     | +-------------+
| HP Coreswitch +-----+-+ Workstation |
+------+--------+       +-------------+
       |
+------+-----+  +-----+
| Homeserver +--+ VM  |
| Proxmox    |  | DNS |
+--+-------+-+  +-----+
   |       |
+--+--+ +--+--+
| VM1 | | VM2 |
+-----+ +-----+

Einbinden der vServer via OpenVPN

Auf jedem vServer der irgendwo gemietet ist läuft ein OpenVPN Server mit folgendem Setup:

  • udp, tun (routing)
  • Vergabe fester P2P IP Adressen via ifconfig Anweisung in der Konfiguration
  • Angabe aller notwendigen Routen via route Anweidung in der Konfiguration
  • Pre-Shared Key (eingebettet in die Konfigurationsdatei)

Bei mir Zuhause habe ich einen OPNSense Router auf einem PCEngines APU3 Board laufen.

Die Konfiguration lässt sich dort zum Großteil unter VPN -> OpenVPN -> Client, Interfaces und Firewall zusammenklicken:

  • udp, tun (routing)
  • Remote Server + Port, Local Port, Pre-Shared Key
  • Für den VPN Client ein Interface (ohne IP, das macht der OpenVPN Client) anlegen
  • Firewall Regeln für das neue Interface konfigurieren

Ein genaues auflisten der Konfigurationsdateien erspare ich mir hier, da es diese schon Zuhauf im Internet gibt. Eine Google Suche nach OpenVPN Peer2Peer Pre-Shared Key sollte das gewünschte Ergebnis bringen.

In allen Fällen übernimmt der vServer die OpenVPN Server Rolle, da dieser immer eine garantiert feste IP Adresse besitzt. So gibt es keine Probleme, wenn sich die IP Adresse meines VDSL Anschlusses ändert. Man muss auch nicht erst auf das DynDNS Update warten.

Einstellungen in den Gästen auf dem vServer

Auf den meisten meiner vServer läuft Proxmox für den Betrieb von LXC Containern.

Jeder Container hat hier ein Interface mit einer lokalen 10.0.0.0/8 IP Adresse, welche zum administrativen Zugriff verwendet wird. Außerdem benötigen nicht alle Container eine öffentliche IP. Hier dient die 10er IP Adresse auch zur Kommunikation der Container untereinander.

Für den Zugriff via VPN muss in den Containern, welche zusätzlich zur internen IP ein weiteres Interface mit einer öffentlichen IP Adresse haben, eine statische Route konfiguriert werden:

# eth0 = Öffentliches Interface
# eth1 = Lokales Interface
# 10.* = Lokales Netz Proxmox
# 192.168.* = Heimnetz
# 188.* = Öffentliche IP

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         188.xx.xx.xxx   0.0.0.0         UG    0      0        0 eth0
10.18.18.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
188.xx.xx.xxx   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.0.0     10.18.18.1      255.255.0.0     UG    0      0        0 eth1

So wird der VPN Traffic über das VPN Interface des vServer als Gateway geleitet. Macht man dies nicht, landet die Antwort auf eine Anfrage über das VPN auf dem öffentlichen Interface und wird anschließend vom Router des ISP verworfen.

Weitere Einstellungen:

  • Nicht öffentlich verwendete Dienste (SSH, Monitoring Agent) auf die 10er IP binden
  • SSH root Zugriff auf 10er IP Adressen begrenzen (Match Address)
  • Via Cron Backups von Datenbanken etc durch das VPN "nach Hause" kopieren
  • ...

Im Heimnetz

An meiner OPNSense Box hängt ein HP 2530-8G-PoEP Switch (J9774A) Switch welcher die einzelnen Ports via VLANs separieren kann und den Unifi Access Point mit Strom via PoE versorgt.

Meine VLANs:

  • LAN: Normales Heimnetz mit Workstations, Notebooks und Smartphones
  • BAD: Geräte wie Chromecast, Amazon FireTV, Daddel-Tablet
  • IoT: Ikea Smart Lampen, gehackte Amazon Dash Buttons
  • SRV: Virtuelle Maschinen des Homeservers, QNAP Backup NAS
  • VPN: Notebooks und Smartphones welche sich via OpenVPN einwählen
  • MGM: Management Netzwerk für Router, Accesspoint, Switches

Die VLANs/Subnetze erhalten alle von der OPNSense Box via DHCP IP Adressen und sind durch die Firewall voneinander separiert.

Die Clients in LAN dürfen überall hin, alle anderen Netze sind stark eingeschränkt. Den Clients in VPN ist zum Beispiel nur die Nutzung des Internets und der Zugriff auf einen einzelnen PC via Remote Desktop gestattet.

Eigener DNS Server

Im lokalen Netz läuft ein Bind9 DNS Server welcher allen Geräten feste DNS Namen zuweist. Jeder Switch, Router, Access Point, Server und auch das Backup NAS sind somit via DNS Namen ansprechbar.

Auf den vServern befindet sich ebenso ein DNS Server welcher die DNS Namen für die LXC Container verwaltet. In den LXC Containern ist dann die 10er IP des vServers als DNS Server eingetragen.

  • lan.example.com -> Clients im LAN
  • srv.example.com -> VMs des Homeservers
  • mm.example.com -> Netzwerkgeräte
  • foo.mox01.example.com -> VM auf Proxmox Server Nr. 1
  • bar.mox02.example.com -> VM auf Promxox Server Nr. 2
  • ...

Für die Zonen welche via DHCP von der OPNSense Box versorgt werden, wird die DNS Anfrage via Forwarding vom Bind9 an die OPNSense Box weitergegeben. So sind auch dynamische Clients via DNS erreichbar.

Auch für die vServer ist jeweils ein Forwarding im Bind9 eingetragen.

Monitoring

Fürs Monitoring setze ich Check_MK ein. Hier sind alle aktiven Netzwerk Geräte (SNMP) und alle Server (Check_MK Monitoring Agent) angelegt und mit Abhängigkeiten versehen. Gibt es Probleme, wird eine E-Mail versendet.

Den Monitoring Agent gibt es als deb und rpm Paket. Verteilt wird dieser via Ansible.

checkmk

Gibt es eine Störung, liegt es entweder an meiner VDSL Leitung oder an dem überwachten Server. Die lässt sich unterscheiden, da zusätzlich noch diverse große Dienste regelmäßig gepingt werden. Ein separates, externes Monitoring ist somit nicht notwendig.

Hallo Internet

Mein Name ist Christian, vom Beruf bin ich Anwendungsentwickler.

In meiner Freizeit beschäftige ich mich mit verschiedensten Technologien. Hier sammele ich Dinge, die für mich interessant waren oder sind.