Robotic in the Clouds - Infrastruktur und Netzwerk

[Ashampoo]

Hallo Freunde,

ich habe da ein Problem. Es geht um die Bereitstellung eines (vorerst) kleinen Clusters bestehend aus aktuell einer Node mit Proxmox. Es sollen bis zu 15 Roboter (Kuka, UR, Mitsubishi, Selbstbau) im Roboternetzwerk sein. In Zukunft kommen weitere hinzu.
Kurz zu mir: ich bin kein Profi in der IT, aber Elektronikingenieur mit Linux- und Software-Hintergrund. Das ganze Projekt ist ein Forschungsprojekt und ich bin als Masterand- und Werkstudent daran beteiligt.

Die Node soll Windows und Linux VMs ausliefern um mit ROS2 und Kubernetes zu arbeiten. Auch sollen die Roboter über etwaige IDEs programmiert werden können. Die IDEs werden über vnc, rdp o.ä. abgerufen.

Nun suche ich nach der best Practice oder State of the Art Methode um die Kommunikation sicherzustellen. Ich habe euch hier einen kleinen Netzplan erstellt:
https://drive.google.com/file/d/1_TInmg50r-shek6ZpSgXXJ8h2QVhIHzA/view?usp=sharing

Wie zu sehen hat der Proxmox Host 3 Netzwerkkarten: eno1, eno2 und eno3. 1 und 2 sind sicht- und konfigurierbar im Proxmox. eno3 dient nur dem Wartungszugriff (ipmi). Eno1 ist das Interface zum Campus/Internet, welches mit wpasupplicant angeschlossen ist. Eno2 ist an den unmanaged Switch des Robonets angeschlossen.

Die Virtuellen Anwendungen sollen, wenn möglich, ins Internet kommen können und sich gegenseitig erreichen. Auch die realen Arbeitsplätze sollen das Robonetz und in das VMNetz erreichen können. Dabei soll die effizienzeste Route verwendet werden. Die Route über das Campus-Netz ist aktuell vlan tagged und unterbindet nicht autorisierte Kommunikation. Da kann ich teilweise die Maschinen nicht anpingen obwohl ich am selben Tisch-Switch hänge. Das Datenpaket geht gemäß VLAN immer über den Switch im Serverraum.


Nun habe ich bereits ein paar Versuche unternommen und bin mir noch nicht super sicher ob das bestPractice ist. Eno1 rühre ich erstmal nicht an. Vorerst ist mein Ziel eine astreine Interkommunikation innerhalb der VMs, der VMs mit den realen Workstations und mit den Robotern zu haben.

Wenn dies funktioniert würde ich versuchen gewisse VM ins Campusnetz zu holen. Unser Admin hat mir vor seinem Urlaub noch was mit NAT an ENO1 gesagt.

Beitrag automatisch zusammengeführt: 31.08.2021

Spoiler: interfaces

auto lo
13 iface lo inet loopback
14
15 auto eno2
16 iface eno2 inet static
17
18 auto eno1
19 iface eno1 inet dhcp
20   pre-up /etc/network/preup.sh
21   post-down /etc/network/postdown.sh
22
23 auto vmbr200
24 iface vmbr200 inet static
25     address 172.31.1.25/24
26   bridge-ports none
27   bridge-stp off
28   bridge-fd 0
29 #Robolan
30
31 auto vmbr100
32 iface vmbr100 inet static
33   bridge-ports none
34   bridge-stp off
35   bridge-fd 0
36 #externADS
37
38 auto vmbr300
39 iface vmbr300 inet static
40   bridge_ports none
41   bridge_stp off
42   bridge_fd 0
43 #vmintern host only
44
45 auto vmbr400
46 iface vmbr400 inet static
47     address 172.31.4.25/24
48   bridge-ports none
49   bridge-stp off
50   bridge-fd 0
51 #robolan 2
52
53 auto vmbr500
54 iface vmbr500 inet static
55   address 172.31.1.24/24
56   address 192.168.1.25/24
57   bridge_ports eno2
58   bridge_stp  off
59   bridge_fd 0
60 # virtual bridge to let vms communicate with robonet

vmbr100 - externe Brücke für die Verbindung in die Welt
vmbr200 - Brücke testweise - wird durch vmbr500 ersetzt, oder? Nur mit 500 kann ich ausserhalb des Hostes kommunizieren
vmbr300 - interne VM Komm
vmbr400 - robonet2 - selbes Problem wie vmbr200
vmbr500 - hier habe ich mal die eno2 miteingehängt und damit scheint die Kommunikation zwischen den VMs und Robonet zu funktionieren.

Nun ist die Frage ob ich auf vmbr500 mehrere Adressen für diese Brücke eingebe oder ich mit eno2:1 eno2:2 arbeite und dann mit Brücken?
Empfiehlt sich generell der Einsatz von OPNsense in meinem Fall? Insbesondere wegen dem DHCP und dem Routing (falls ich das brauche).
Welche Probleme seht ihr auf uns zukommen?
Sollte ich über software defined network (als eigenes Subnetz im Campus) nachdenken?

 

[Ashampoo]

Den Thread habe ich auch im proxmox forum laufen. Da kamen bereits Fragen und ich habe das Diagram geupdated:

 

[Hexcode]

Aus Security Sicht haben die VMs die irgendwie nen Bein in nem Produktionsnetz hängen eigentlich nichts im Internet zu suchen. Gerade bei so Roboter-Armen halte ich das sonst echt für fragwürdig wenn da jemand die Maschine kapern könnte die den Arm steuert. Maximale der Gefühle wäre dann ein besonderes geschützter Jumpserver der dann wiederum diese VMs erreichen kann.

Weiterhin würde ich immer mit statischen Adressen arbeiten und nicht DHCP. Wird doch nicht so sein dass da ständig neue Maschinen dazu kommen?

 

[Ashampoo]

Da hast du Recht. Aber was ist der Unterschied ob nun meine VMs oder Workstations im Internet hängen? Kann ich VMs leichter übernehmen als Blackhat? Von außen kommt man eh nur über das CampusLAN rein. Das heißt, da ist erst eine Passwort-Authentifikation am login.xx.de oder ein VPN notwendig. Und von dort aus kann ich an den, ich glaube das heißt, RadiusServer und dann per Hostname auf die Maschinen.

Ob da nun die VMs oder Workstation als Endpunkt ist..?

 

[Hexcode]

Die Workstations auf denen täglich gearbeitet wird sollten grundsätzlich keinen direkten Zugang zum Produktionsnetz haben. Deshalb ist das Beinchen hinten Rum zum Produktionsnetz (in deinem Bild da rechts) eigentlich tabu.
Was macht ihr den konkret? Deine VMs steuern später die Roboter oder? Heißt eigentlich bräuchte die Workstation doch Zugang zur VM? Dann würde ich hingehen:
Eigenes VLAN/Lan für die Roboter. Der Proxmox hängt dann mit darin für deine VMs, die dann einbeinig darinnen hängen. Die VMs haben dann wieder Access zu besagten Jumpserver (kann auch eine VM sein), die wiederum dann Richtung eurer Workstations spricht.
Dann dürfen haben deine Steuerungsvms keinen direkten Weg zu den Workstations und co und können folglich nicht direkt übernommen werden. Der Jumpserver sollte mittels Firewall dann zusätzlich gesichert sein, so dass da nur die benötigten Ports offen sind und alles andere nicht.

Der Unterschied liegt darin, das die Wahrscheinlichkeit gegeben ist das ihr euch auf den Workstations irgendwas runterladen oder über ne Mail einfangt. Wenn das alles in einem Segment hängt machen die Roboter dann plötzlich lustige Dinge oder die Produktion fällt aus. Wohingegen bei sauberer Trennung im Idealfall nur die Workstations neu aufgesetzt werden müssen, davon aber nicht die Produktion betroffen ist.

 

[underclocker2k4]

Kann mich da Hexcode nur anschließen.
Im Idealfall holt man sich da einen Netzwerkarchitekten mit Security ins Boot.
Nicht gegen dich, aber sowas sollte man keinem Studenten überlassen und schon garkeinem, der keinen IT-Security background hat.

Mit sicherheitsgerichteten Applikationen spielt man nicht. Es gibt da noch sowas wie die Maschinenrichtlinie und andere lustige Normen wie z.B. die 62443.

1. Die Robis kommen in eine Sec-Zone
2. Die Programmierstationen kommen in eine weitere Sec-Zone.
3. Die Sprungrechner kommen in eine weitere Sec-Zone.
Alle drei Zonen sind kaskadiert und durch Firewalls getrennt.

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/network_segmentation.pdf

Bild 1 beschreibt das ganz gut.
Im Idealfall ist das Routing in den Zone unterbrochen (die Firewallinterface sehe sich nicht direkt) und die dort installierten Maschinen hängen mit je einem Interface an den für die Zone zuständigen Firewallinterfacen.
So muss neben dem Überwinden der Firewall und deren Policy auch die Maschine übernommen werden, damit eine Kommunikation von Firewall zu Firewall durchlässig wird.
Und ja, man kann dann aus den unteren Zone nicht ohne weiteres ein "apt-get" aus nem inet Repo machen, aber auch dafür gibt es Lösungen.
Die Sprungrechner machen nichts anderes wie ne Konsole für die Programmierrechner bereitzustellen, z.B. Remotedesktop. Auf dem Rechner läuft nichts, keine Software, gar nichts. Die User haben keine Rechte und sonstiges.
Die Programmierrechner haben alle Software die sie brauchen und im Idealfall auch keine Rechte.
L2-Kommunikation zwischen Programmierrechner und Robis ist selten notwendig.

Das, was du da aufbaust, gibt es bereits 1000000x auf dem Planeten und die Ergebnisse sieht man regelmäßig in den Schlagzeilen. Primär geht es da zum Glück nur um Produktionsstillstände.
Ein prominentes Beispiel aus jüngster Vergangenheit.

Symrise verfehlt wegen Hacker-Angriff Umsatzziel 2020 - Symrise-Aktie leicht im Minus

Der Duft- und Aromastoffhersteller Symrise hat im vergangenen Jahr unter der Corona-Pandemie und einem Cyber-Security-Angriff Mitte Dezember gelitten.

www.finanzen.net

Ich hatte letztens ne Firma, die durften über länger ihre Laptops nicht mehr benutzen, weil sie ein Securityproblem hatten.
(das löst man natürlich nicht nur durch Firewall und nen paar Netzwerkstrippen)

Das ist dann der Börsenbericht dazu.

Cyber-Security: The Next Big Thing?

Ein Hackerangriff legt die Produktion des deutschen Aromaherstellers und Dax-Kandidaten Symrise lahm. Es ist das nächste Beispiel dafür, dass eine bestmögliche Cyber-Sicherheit im Zeitalter der Digitalisierung für Unternehmen essentiell ist. Anleger können von diesem erzwungenen Zukunftstrend...

www.boerse-am-sonntag.de

Die Digitalisierung treibt auch die Security und das aus gutem Grund.
Dein Konstrukt hat aktuell, bis auf den 802.1x, nichts mit Security zu tun.

EDIT:
Ob nun VM oder Phy ist egal. Am Ende gehts immer um 2 Interface, die da rein müssen. Das kann auf dem VM-Host auch VLAN sein, mit dedizierten vSwitches.
Wobei es da auch ein paar Spitzfindigkeiten gibt, z.B. wie getrennt ist der Verkehr im VM-Host denn wirklich. Aber das lassen wir erstmal außen vor.

 

[Ashampoo]

Moin,

ich hab mal eure Punkte bzw. direkt den Link zum Thread an unsere Admins geschickt. Ich sehe das im Allgemeinen auch so. Mal schauen, was deren Meinung ist.


Zum Einsatzgebiet: Es ist ein studentisches Labor und die Roboter bewegen sich aktuell 5 min pro Woche. Produktiveinsatz gibt es nicht. Dennoch steht Sec an hoher Stelle.


In jedem Fall danke ich euch beiden und besonders für die vmware PDF. Genau so was habe ich gesucht. Für eine vernünftige Weiterführung dieses Threads muss ich erst mal eure beiden Beiträge verstehen und nachschlagen.