Zweite virtuelle Netzwerk-Karte (zusätzliche IPv4) im vServer für OpenVPN-Client nutzbar?

    Ich habe folgende Anforderung:


    vServer (VPS) mit Login-geschütztem Portal für meine Kunden. Zugang über das „öffentliche“ Internet über die erste, im VPS-Paket enthaltene vNIC. Parallel soll auf dem vServer ein OpenVPN-Client (Client, nicht Server!) laufen, der eine getunnelte Verbindung zum OpenVPN-Server eines IoT-Anbieters aufrecht hält, über den die Kommunikation zwischen dem Portalkonto meines Kunden und seines mobilen IoT-Endgeräts läuft. Hierfür brauche ich eine zweite (virtuelle) Netzwerk-Karte.


    Die Datenmengen sind sehr gering, so dass die Bandbreite der Netzwerk-Karte absolut zu vernachlässigen ist, weshalb eine vNIC theoretisch ausreichend wäre.


    Die Frage, die sich nun stellt: Ist die Erweiterung Zusätzliche IPv4 für EUR 0,99 für die beschriebene OpenVPN-Client-Anwendung nutzbar? Stichwort: Zuweisung einer IP-Adresse durch den gegenüber befindlichen OpenVPN-Server:

    Ich verstehe nicht so ganz, warum du eine weitere vNIC brauchst.


    Du musst dem OpenVPN Client doch nur sagen, dass da nur Netz XYZ hängt und das nicht der default Gateway ist. Und schon sollte das ganze passen.


    Eine zusätzliche IPv4 Adresse ist weder eine zusätzliche vNIC, noch kann ich mir vorstellen, dass sie in deiner Situation helfen könnte.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from TheWoo

    Parallel soll auf dem vServer ein OpenVPN-Client (Client, nicht Server!) laufen, der eine getunnelte Verbindung zum OpenVPN-Server eines IoT-Anbieters aufrecht hält, über den die Kommunikation zwischen dem Portalkonto meines Kunden und seines mobilen IoT-Endgeräts läuft. Hierfür brauche ich eine zweite (virtuelle) Netzwerk-Karte.

    Wieso eigentlich? Dem OpenVPN-Client ist es ziemlich sicher egal, über welche IP er rausgeht. Innerhalb des VPNs wird sowieso ein tun/tap erstellt, das den IP-Range des Servers nützt.

    Der OpenVPN-Server des IoT-Anbieters weist meinem OpenVPN-Client auf dem VPS dynamisch eine eigene IP-Adresse aus seinem Adress-Pool zu. Gleichzeitig muss meine Website mit dem Portal für meine Kunden aber unter einer anderen, festen IP-Adresse erreichbar sein. Wie soll das (zwei verschiedene IP-Adressen, eine davon fest, die andere dynamisch zugeteilt) mit nur einem „Netzwerk-Anschluß“ funktionieren?

    Quote from TheWoo

    Der OpenVPN-Server des IoT-Anbieters weist meinem OpenVPN-Client auf dem VPS dynamisch eine eigene IP-Adresse aus seinem Adress-Pool zu. Gleichzeitig muss meine Website mit dem Portal für meine Kunden aber unter einer anderen, festen IP-Adresse erreichbar sein.


    Wie soll das (zwei verschiedene IP-Adressen, eine davon fest, die andere dynamisch zugeteilt) mit nur einem „Netzwerk-Anschluß“ funktionieren?

    OpenVPN erstellt doch ein eigenes virtuelles Netzwerk Interface (z.B. tun0). Ich verstehe da jetzt das Problem nicht... :/

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from eripek

    Wieso eigentlich? Dem OpenVPN-Client ist es ziemlich sicher egal, über welche IP er rausgeht. Innerhalb des VPNs wird sowieso ein tun/tap erstellt, das den IP-Range des Servers nützt.

    Dem OpenVPN-Client mag es egal sein, aber ich glaube dem OpenVPN-Server nicht.

    Das sind doch alles eigenständige und virtuelle Netzwerk-Interfaces. Davon kannst du in Linux quasi unbegrenzt viele Erzeugen.

    "Security is like an onion - the more you dig in the more you want to cry"

    Die Konstellation ist doch im Normalfall die, dass der OpenVPN-Client auf einem hohen Port eine Verbindung zum Default-Port 1194/udp eine Verbindung zum Server aufbaut. Je nachdem, ob der Server auch Default-Gateway ist oder nicht, muss man eine statische Route zu dessen externer IP einrichten, um zu gewährleisten, dass er erreichbar bleibt (tut man das nicht, und sind auf dem Server widerstrebende Einstellungen gemacht worden, flappt der Tunnel).


    Der Server teilt üblicherweise dem Client eine Adresse und eventuell noch Routen zu. Server und Client sprechen über deren externe Adressen (der Client darf auch hinter NAT/CGN sein) miteinander. Lokal wird ein tun-Interface oder ein tap-Interface angelegt, um ein internes Netzwerk zu etablieren.


    Wenn Deine Kunden auf Deinem Portal zugreifen, und Dein Portal die Anfragen dann über den IoT-Anbieter-Tunnel sendet, um die Kommandos zu den IoT-Geräten zu senden, sehe ich noch immer keinen Bedarf für eine zweite IP oder gar ein zweites Interface.


    Hast Du mehr Details oder Spezifikationen des IoT-Anbieters? Du musst bitte auch klären, ob es wirklich der Client/Server-Mode oder nicht doch der P2P-Mode von OpenVPN ist, der hier verwendet wird.

    Quote from TheWoo

    Dem OpenVPN-Client mag es egal sein, aber ich glaube dem OpenVPN-Server nicht.

    What? Der OpenVPN Server gibt dir vermutlich eine Unique Local Address (oder eine private IPv4 bei veralteten Konfigurationen).


    Und selbst wenn der OpenVPN Server Betreiber sagt "ja wir haben ne Firewall und wollen wissen von welcher IP du kommst" - na dann nimmst du die normale von deinem Server und gibst die denen. Wo ist denn da jetzt das Problem?


    Ich habe ein bisschen Gefühl, dass du nicht wirklich weißt, was du da tust und mit 1 Gbit/s oder mehr ans Netz stellst. :/

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Also ich betreibe auch Server, die als openVPN Client im einem VPN hängen und gleichzeitig über die öffentliche Adresse auf Port 80 einen Webserver lauschen haben. Alles ohne zusätzliche öffentliche IP Adresse. Ein Server kann auch so problemlos 2 Netzwerkinterfaces haben. Z.B. eth0 mit öffentlicher IP und tun0 mit 10.8.0.0/24 Adresse. Dem openVPN Server ist es herzlich egal, ob dein Client auf der öffentlichen IP noch Ports offen hat.


    Du solltest dir vielleicht noch ein paar Infos zum Thema Routing, openVPN, Firewall, IP Netzwerke anschauen, bevor du sowas im Internet betreibst. Du willst ja wahrscheinlich nicht, dass dein Server ohne vernünftig konfigurierte Firewall eine Gefahr für die anderen Server im VPN ist.

    Die "Public IP" an dem blauen Kästchen ist nicht die IP, die vom Openvpn Server vergeben wird. Da entsteht noch ein virtuelles Interface (tun), das nur innerhalb des "Customer Application Server" sichtbar ist, und das erhält die Adresse vom Openvpn-Server.

    Ich muss gestehen, dass ich nur der halbwissende Fragesteller bin, nicht mein im Hintergrund befindlicher, „wissenderer“ Techniker, für den OpenVPN aber auch ein wenig Neuland ist.


    Ich habe die Anforderung bzgl. der zweiten NIC falsch verstanden, weshalb meine ursprüngliche Frage falsch gestellt war. Es geht nicht wie beschrieben um Internet-vs.-VPN-IP-Adressen vs. Netzwerk-Adapter, als vielmehr um die Erreichbarkeit, wie ich jetzt verstanden habe. Konkret:


    Option A (wie von Euch hier erwähnt) – 1 (physische) Netzwerkkarte

    Darauf der „Link“ ins Internet. Hier kann man jetzt auch das OpenVPN aufschalten. Allerdings ist die virtuelle (logische) Netzwerkkarte (hier: tun0) dann auch drauf. Die teilen sich also dasselbe „Kabel“.


    Option B – 2 (physische) Netzwerkkarte

    Eine für den Internet-Zugang, eine für das OpenVPN.


    Der Gedankengang dahinter:


    Wenn bei Option A irgendwas falsch läuft (falscher Gateway eingetragen, falsches Was-auch-immer ...?) -> dann purzelt dieser Rechner ohne Zugriffsmöglichkeiten aus dem Internet, irgendwo (hoffentlich im VPN) rum.


    Wir kommen dann aber nicht mehr – im Sinne von überhaupt nicht mehr – auch nicht über das WCP/PleskUI –, also wirklich gar nicht mehr auf die Kiste, wenn wir das richtig sehen. Da muss also ein Netcup-Support-Mitarbeiter hin und den VPS neustarten. Oder ans lokale Terminal.


    Bei Option B könnten wir immer noch von außen über das eine Interface drauf zugreifen, weil das VPN ja separat auf der zweiten Netzwerkkarte (natürlich auch als virtuelles tun device) läuft.


    Macht das Sinn, oder ist das Humbug? Und: Braucht es für diese Trennung eine „echte“/dedizierte NIC (diese EUR 34,80-Option) oder genügt da besagte zusätzliche IPv4 zu EUR 0,99?

    Quote from TheWoo

    Wir kommen dann aber nicht mehr – im Sinne von überhaupt nicht mehr – auch nicht über das WCP/PleskUI –, also wirklich gar nicht mehr auf die Kiste, wenn wir das richtig sehen. Da muss also ein Netcup-Support-Mitarbeiter hin und den VPS neustarten. Oder ans lokale Terminal.

    Wer hat dir denn diesen Schwachsinn erzählt? Netcups Server sind KVM Kisten auf die du mit der VNC Konsole im SCP jederzeit drauf kannst, gefühlt auch wenn du an der Netzwerkschnittstelle ne Nuklearkatastrophe erzeugt hast.


    Du brauchst nach wie vor keine zweite IP Adresse. Die Skizze ist faktisch falsch. Das OpenVPN geht durch deinen Internet GW durch und erzeugt im Server ne virtuelle NIC.



    Ganz ehrlich - wenn du/ihr nicht genau wisst, was ihr da tut und und wie ihr das sicher und stabil aufbauen müsst, dann lasst die Finger davon und lasst das andere machen, die Ahnung davon haben. Sonst macht ihr euch da nur selbst unglücklich und mehr Ärger, als ihr denkt.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Verstehe. Quasi das, was das IPMI an meinem ASRock Rack Server Board meines heimischen NAS ist.

    Quote

    Ganz ehrlich - wenn du/ihr nicht genau wisst, was ihr da tut und und wie ihr das sicher und stabil aufbauen müsst, dann lasst die Finger davon und lasst das andere machen, die Ahnung davon haben. Sonst macht ihr euch da nur selbst unglücklich und mehr Ärger, als ihr denkt.

    Hach, wie ich das liebe, dass man in derartigen Foren immer direkt eins mit der Keule übergebraten bekommt, wenn man nicht annähernd das Wissen mitbringt, das erforderlich wäre, um die Fragen, die man hat, erst gar nicht stellen zu müssen...

    Früher mal Sesamstraße geschaut?

    Quote

    Der, die, das,
    wer, wie, was,
    wieso, weshalb, warum,
    wer nicht fragt, bleibt dumm!

    Die Betonung liegt hier auf bleibt!

    Quote from TheWoo

    Hach, wie ich das liebe, dass man in derartigen Foren immer direkt eins mit der Keule übergebraten bekommt, wenn man nicht annähernd das Wissen mitbringt, das erforderlich wäre, um die Fragen, die man hat, erst gar nicht stellen zu müssen...

    Nun, Du hast hier einiges an Halbwissen in den Mixer geworfen, und der Cocktail daraus trifft die Geschmacksnerven wie ein Blitz.

    1. WCP ist das Webhosting Control Panel - damit steuert man die Hosting-Produkte von netcup. WCP ist ein modifiziertes Plesk.

    2. OpenVPN läuft bei netcup für gewöhnlich nur auf virtuellen Maschinen - also auf den RS oder VPS-Serien, wenn man von den dedizierten Servern und managed Servern einmal absieht.

    3. Es gibt tatsächlich Zusatzprodukte, die virtuelle oder physische Netzwerkadapter und/oder zusätzliche IP-Adressen bereitsstellen - Du findest sie unter https://www.netcup.de/vserver/root-server-erweiterungen.php (Hardware) oder https://www.netcup.de/professi…eserver-erweiterungen.php

    4. Dass für Deinen Anwendungszweck eine der Erweiterungen gem 3. notwendig wäre, darf bezweifelt werden.

    5. Du könntest ja auch Deinen Techniker vorschicken, um die Fragen zu klären.

    6. Der Vergleich mit IPMI hinkt etwas. Das Servercontrolpanel (SCP) ist ein Webinterface, das die Funktionen von libvirtd ansprechen dürfte. Es ermöglicht, dass Du Bootmedien einbindest, Backups/Snapshots erstellst, Feintuning machen und VLANs (soweit gebucht) einbinden kannst, sowie die Statistiken anzuzeigen.


    Ich verstehe, dass das zum Teil Neuland ist, aber dafür gibt es ja auch das Wiki https://www.netcup-wiki.de/wiki/Hauptseite.


    Wenn meine Mitposter hier die Fassung verloren haben, liegt es eventuell auch daran, dass wir hier in diesem Kundenforum zu Zeiten, wo Schulferien sind, teilweise mit haarsträubende Fragen konfrontiert werden. Vieles davon ist sicherheitstechnisch bedenklich, und nicht selten bekommen wir den Eindruck, dass Menschen, denen einfach grundlegende IT-Kenntnisse fehlen, sich schnell einmal einen billigen Server nehmen und kurz darauf auch schon wegen des Missbrauchs eines Dienstes (Spam, Filesharing, Mining) wieder gesperrt werden. Das ist auch für uns andere Kunden höchst unangenehm, weil etwa Microsoft eine gewisse Tendenz hat, Blacklists zu setzen, die den gesamten IP-Bereich von netcup vom Mailversand aussperren, selbst, wenn es sich um legitime Aussendungen handelt.