Für verschiedene Kunden-Szenarien VPN-Router in der Werkstatt virtualisieren

Wir machen ja viel, also sehr viel, über VPN, das schließt die Neuinstallation von Kunden-Systemen (PC und Notebooks, ggf. auch Server) mit ein.

Daher kommt sehr oft S2S (Site-to-Site VPN) zum Einsatz. Früher wurde dazu eine pfSense (CE) auf einem PC Engines-Board verwendet. In der Regel wurde einmal ein entsprechendes VPN eingerichtet, dann eine Datensicherung der pfSense erstellt und bei Bedarf, gemeint ist anderer Kunde, das jeweilige Backup wieder eingespielt. Das hat soweit recht gut funktioniert. Nachdem es mit WireGuard und pfSense (bei uns) nicht so recht wollte und ich zudem aufgrund diverser Probleme mit der pfSense CE immer unzufriedener wurde musste eine andere Lösung her.

Nebenbei bemerkt: Mit OPNsense bin ich nie richtig warm geworden, ferner bekam ich dort Wireguard irgendwie auch nicht ans laufen, daher war das (für uns bzw. für mich) keine Option.

Wie bereits im oben verlinkten pfSense/WireGuard-Beitrag erwähnt klappt das Thema S2S mit WireGuard mit OpenWRT erfreulich gut, daher sollte es dabei bleiben. Allerdings hatte ich schlicht keine Muse OpenWRT auf PC Engines zu installieren, möglich ist es alle Mal, aber mir war da ein etwas anderer Weg sympathischer und um genau den geht es hier.

Wie bereits erwähnt machen wir sehr viel via VPN, damit man nun von diesem Backup/Restore der Router-Konfiguration nun etwas weg kommt (naja eigentlich anders macht) führt der Weg nun über Virtualisierung. D.h. man nehme beispielsweise einen (ausrangierten) PC oder Server, installiere eine Virtualisierungslösung der Wahl darauf und nutzen OpenWRT als virtuelle Maschine (VM). Das hat (imho) den Vorteil das man mehrere Instanzen gleichzeitig laufen lassen kann, was sehr hilfreich ist wenn man mehrere Kunden gleichzeitig bedient, und vor allem muss man nicht von immer erst die passende Konfig. wiederherstellen.

Im einfachsten Fall hat man eine VM bei der je nach Bedarf eine entsprechend vorbereitete virtuelle Festplatte verwendet wird, also z.B. (unter Hyper-V) “KundeA.vhdx”, “KundeB.vhdx”, usw. oder man erstellt pro Kunde eine eigene “Router-VM” und startet dann eben nur das was man gerade braucht. Das Ganze funktioniert am besten wann man der Virtualisierung-Host mindestens zwei Netzwerkkarten hat und/oder man VLAN nutzt. Aus Platzgründen habe ich das nun bei uns in der Werkstatt mit einem altem HP ProDesk 600 G2 SFF (Intel Core i5-6500, 8 GB DDR4,  120 GB SSD) gelöst, dem eine zusätzliche Low-Profile Netzwerkkarte (die auch noch über war) spendiert wurde. Des Spaßes halber wurde mal Windows Server 2022 Standard (mit Hyper-V Rolle) installiert, was komplett ohne irgendwelche Verrenkungen funktioniert hat. Es musste noch nicht mal irgendein Treiber händisch heruntergeladen oder installiert werden, was nicht Onboard (im Setup) war kam via Windows Update. Wenn es doch nur immer so einfach wäre.

Um es klar zu machen: Das ist jetzt keine Empfehlung um aus einem PC einen Server zu machen! Das ist eine Bastellösung ohne jedweden Support den wir gemacht haben und eben bei uns in der Werkstatt läuft. Beim Kunden würde ich das nicht hinstellen (wollen).

OpenWRT läuft da bereits produktiv drauf und aktuell schaufelt ein neuer Kunden-Server (der hinter diesem VPN-Router steht) über VPN die Daten (Erst-Abgleich von File-Shares) auf sich drauf.

Tipp am Rande Nr.1: Eine zusätzliche VM anlegen mit einem Windows/Linux-Desktop samt Browser und üblicher Tools darin, so lässt sich OpenWRT leicht verwalten und das VPN prüfen.

Tipp am Rande Nr.2: Eine Port-Weiterleitung für das Web-Interface von OpenWRT einrichten (Natürlich nur wenn vor diesem Router noch eine Firewall steht!) um leichter das System verwalten zu können.

Kurzum: Mit wenig Aufwand und noch dazu günstig eine (imho) performante und zudem flexible Lösung. Ich bin sehr zufrieden.

1 Kommentar

  1. Martin Kuras

    … man könnte noch erwähnen, dass die Hyper-V Netzwerkinterfaces standardmäßig kein VLAN(s) durchlassen und es per GUI keine Möglichkeit gibt das zu ändern.

    Beispiel, VM “pfSense” mit zwei Netzwerkinterfaces, LAN soll getaggte VLANs von 10 bis 200 durchlassen.

    # Netzwerinterface benennen (um sie einfach(er) unterscheiden zu können)
    $VMNetAdap = Get-VMNetworkAdapter -VMName pfsense
    $VMNetAdap[0]
    $VMNetAdap[1]
    rename-VMNetworkAdapter -VMNetworkAdapter $VMNetAdap[0] -newname LAN
    rename-VMNetworkAdapter -VMNetworkAdapter $VMNetAdap[1] -newname WAN

    # LAN-Netzwerkinterface für getaggte VLANs einstellen
    Set-VMNetworkAdapterVlan -VMName pfSense -VMNetworkAdapterName LAN -Trunk -AllowedVlanIdList “10-200” -NativeVlanId 0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

© 2024 Andy's Blog

Theme von Anders NorénHoch ↑