über OpenVPN auf Client mit 3-Netzwerkarten zugreifen und Routen der Netze

Das ist alles etwas wirr formuliert von dir.

Verstehe ich das richtig:
Du möchtest mittels OpenVPN auf diesen besagten Client-PC (161.33.10.233) zugreifen um von dort aus, dann auf das SPS und auf das Prüfsystem zugreifen zu können?
Auf dem Client-PC läuft bereits ein OpenVPN Server auf den du erfolgreich einen Tunnel aufbauen kannst und Zugriff drauf hast?
Wie sehen die Routen auf diesem Client-PC aus?
Dann halten wir trotzdem fest:
Du verwendest public IPs, das DARFST du nicht!
Ein Windows Client ist die SCHLECHTESTMÖGLICHE Variante so etwas umzusetzen.

Was mir an Infos noch fehlt ist:
WAS/WER stellt den Internetzugang her für diesen Client PC?
Da muss es ja einen Router/Firewall/whatever geben?

Mmhhh, ist das 161.33er Netz deinst bzw. arbeitest du für Konica Minolta USA ??

NetRange: 161.33.0.0 - 161.33.255.255
CIDR: 161.33.0.0/16
NetName: KONICA-MINOLTA-PRINTING-SOLUTIONS-USA-INC
NetHandle: NET-161-33-0-0-1
NetType: Direct Assignment

Denen ist diese IP weltweit fest zugeteilt worden und es ist sehr töricht wenn du für ein privates Netz deren öffentliche IP nutzt. Jeder Grundschüler weiss heutzutage das man für private Netz den weltweit bekannten RFC 1918 Standard nutzt mit diesen IP Adressen:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
Mit öffentlichen IPs ist das natürlich sehr kritisch, aber es sollte dennoch klappen.

Leider ist deine Beschreibung sehr oberflächlich, denn du postest hier weder deine OVPN Server Konfig noch die der Clients.
Dafür wird es auch für uns hier ein ziemlicher Blindflug und wir müssen die Kristallkugel mal wieder zur Hilfe nehmen.
Zudem ist deine Zeichnung ziemlich wirr und extrem unübersichtlich, sorry.
Man schafft es nicht auch nach intensiver Betrachtung daraus zu ersehen wo die VPN Tunnel sind und wer hier mit wem kommuniziert.
Also wenigstens die OVPN Konfig Dateien brauchen wir und eine etwas übersichtlichere Zeichnung so wie du sie hier z.B. im OVPN_Tutorial siehst wären sehr hilfreich um zu einer Lösung zu kommen. Denn funktionieren so wie du es willst tut das ganz sicher.
Sehr hilfreich wäre auch noch ein Output der Routing Tabellen der OVPN Teilnehmer ! (Server u. Client)
Bei aktivem Tunnel bitte mal ein route print posten (Winblows) um zu sehen ob die einzelnen Geräte überhaupt die Routen in deine Zielnetze kennen und du sie entsprechend in den OVPN Konfig Dateien bekannt gemacht hast ?!
Hier liegt meistens der Fehler der gemacht wird. Sehr wahrscheinlich auch bei dir.
Außerdem solltest du die Winblows Firewall immer auf dem Radar haben, denn die treibt auch am virtuellen Tunnel Interface ihr Unwesen und will entsprechend angepasst werden bei OVPN !!

Was verstehst du unter "NKen" ?
Ganz sicher muss er das !! Bitte erst wasserdicht klären bevor wir hier ins Eingemachte gehen !
Machen kann man das schon. Es birgt aber Risiken, denn die IANA IP Range ist nicht für dich registriert. Öffentlich verwendete IP Adressen zu verwenden ist nicht die feine Art und zeigt eher das hier jemand nicht wirklich weiss was er tut beim IP Adressdesign. Gerade und insbesondere wenn man über öffentliche Netze arbeitet.
Das weiss aber jeder Azubi im ersten Lehrjahr heutzutage auch das man so einen Fauxpas nicht macht.
Nichtsdestotrotz wird es auch mit deinen dir nicht gehörenden 161er Adressen klappen.

Die Client Routing Tabelle stimmt soweit. Du hättest sie etwas ökonomischer gestallten können und statt der Einzelnetze einfach ein:
ip route 161.33.0.0 255.255.192.0 <gateway_ip>
In die OVPN Konfig setzen können, dann würden ALLE deine 162.33er Subnetze (von .0.0 bis .63.0) mit einer einzigen Summary Route in den Tunnel geroutet.
Würde auch mit einer /16er Route gehen statt des obigen /18er Prefixes, das beinhaltet dann alle 161.33.0.0er Netze.
Aber egal, es geht auch über die umständliche Art..ist nur aufwändiger vom Routing Setup.
Wenn du mal ein Traceroute auf die Zielnetze oder nur das LAN Interface des Servers machst, klappt das ?
Wenn nicht wo stoppt der Hop ? An diesem Punkt fehlt meistens dann die Route oder es ist die Firewall die dort zuschlägt.

Deshalb bin ich auch der Meinung, dass du nicht der richtige Ansprechpartner für deinen Kunden bist, dieses Vorhaben umzusetzen.
Diese IP Adressen die du hier verwendest gehören wie Kollege @aqui schon sagt der Firma Konica Minolta in den USA.
Du solltest dich an RFC 1918 Adressen halten um dein Vorhaben umzusetzen.

Es ist einfach generell eine komplett falsche Herangehensweise zu diesem Projekt.

Im Normallfall würde der Kunde dir einen VPN Zugang auf seiner Firewall einrichten und dir über Firewall Regeln Zugriff auf die Systeme gewähren die du für die Fernwartung benötigst. Ende der Geschichte.

Oha...du machst ein Bridging über den Tunnel
dev-node tap-bridge
Das sollte man niemals machen wenn man nicht wirklich zwingend muss !
OVPN rät selber strikt davon ab und auch jeder Netzwerker kennt die goldene Regel: "Route where you can, bridge where you must !"
Ganz ehrlich... Baue dein übles Bridging Szenario auf ein sauber geroutetes um. So im Bridging Mode kann das nicht funktionieren. Allein schon weil du ein Masken Mismatch Probklem so bekommst. Kein Wunder das die Kommunikation netzübergreifend dann fehlschlägt.
Im Bridge Mode sind natürlich Sachen wie push route... und sowas vollkommen obsolet, denn ein Routing gibt es ja nicht mehr. Du machst ja dann nur noch dummes Layer 2 Bridging auf Mac Adress Basis !
Bridging bedingt ja das du an ALLEN Tunnelendpunkten die gleiche IP Adresse im loaklen Netz hast. Tödlich...
Ein Bridging bringt zudem sämtlichen Broad- und Multicast Traffic aller beteiligten Netze in den Tunnel, was massiv die Performance in den Keller zieht. Willst du das wirklich ??
Das ist vermutlich der grundlegende Kardinalsfehler den du in deinem Setup machst.
Bridging und IANA registriertte IPs...das lässt wirklich vermuten das du nicht wirklich weisst was du da tust, sorry...
Dein ganzes OVPN Konzept ist damit eigentlich ad absurdum geführt, denn du mischst hier eine OVPN Bridging Konfig mit Routing in einem eigentlich gerouteten Umfeld.
Klar das das von vorn herein in die Hose gehen muss....
Fazit: Sauberes OVPN Routing aufsetzen, dann klappt das auch !