Ich schätze, die Antwort ist einfach....
... vielleicht kommst Du selber drauf... bei mir laufen
zwei Instanzen (als Daemon, was aber egal ist), und das sieht so aus:
Code: Alles auswählen
ps -aux | grep openvpn
vpnuser 868 0.0 0.0 48164 836 ? Ss Mai02 0:50 /usr/sbin/openvpn --daemon --config /etc/openvpn/server_udp.conf
vpnuser 983 0.0 0.0 48272 3396 ? Ss Mai02 0:44 /usr/sbin/openvpn --daemon --config /etc/openvpn/server_tcp.conf
thomas 14788 0.0 0.0 12780 940 pts/0 S+ 16:20 0:00 grep openvpn
Du müsstest jetzt nur herausfinden, wer oder wodurch die weitere Instanz gestartet wird. Ich vermute über...
/etc/default/openvpn->AUTOSTART="all",
... was Du mal prüfen solltest.
king-crash hat geschrieben: 21.06.2019 15:01:07
Der Tunnel wird zu einem Bekannten aufgebaut die config stammt nicht von mir, ich habe mich damit nicht nähers befasst. Wo genau siehst du Sicherheitsprobleme?
Tja, das ist schwierig zu beantworten... auf den ersten Blick halte ich die ganze Konfiguration für ein enormes Sicherheitsrisiko oder besser gesagt, für eine Konfiguration ohne Sicherheit... ob es das aber auch wirklich ist, hängt im wesentlich davon ab, wann Du von wo, was und wie oft mit welchem Ziel vorhast und wie (permanent?) der Server auf Verbindungen wartet.
Es sind mehrere Punkte in der Conf, die der verantwortliche Admin konkret erklären können sollte, warum die hier gewählt wurden und warum die bei dem Szenario kein Sicherheitsrisiko darstellen. Ich betrachte das jetzt nur aus meiner subjektiven Perspektive, weil ich mich primär mit meinem Laptop an unbekannten und damit für meine Hardware potentiell gefährlichen Accesspoints anmelde, um mich dann via OpenVPN zu meinem Server nachhause zu verbinden.. was also bestimmte sehr strenge Anforderungen an die Sicherheit beinhaltet.
Also folgende Fragen?
1. Warum Bridging (tap-Device) und kein für On-The-Fly-Verbindungen besseres und performanteres Routing (tun-Device)?
2. Warum nur die unsichere CA und PWD-Auth, was m.M.n. überhaupt keine Sicherheit bietet?
3. Warum keine TLS-Veschlüsselung mit einem zugriffgeschützten Keyfile für den Verbindungsaufbau?
4. Warum keine zugriffsgeschützten Key-Files für eine sichere Verschlüsselung?
5. Wo sind in der Conf überhaupt die Key-Files angegeben oder wurde darauf verzichtet?
Um Deine Konfiguration nachzuvollziehen, müsste man viel mehr Informationen haben, ohne die kann man nur raten.....aber bei einer Aussage bleibe ich: Wenn Du die Konfiguration nicht erklären und den Aufbau begründen kannst, ist die Sicherheit ein Zufallsprodukt. In dem Fall würde ich tatsächlich auf eine einfacher zu handhabende Pubkey-SSH-Verbindung auf einem Phantasie-Port zurückgreifen, bei der die lokale Keyfile-Verwendung Password-gesichert ist. Der Phantasie-Port dezimiert nachhaltig das Rauschen auf der Leitung.
Wenns Dich interessiert, kann ich Dir mal nen Link senden, wo ich ich meinen Aufbau beschrieben habe.