Azure VM RDP Zugriff via openVPN absichern

bensonhedges
Goto Top
Hallo liebes Forum,

testweise habe ich mit eine Azure (Win) VM eingerichtet und kann per default via RDP (TCP 3389) über die feste IP auf die VM zugreifen.

RDP-Zugriff möchte ich natürlich nicht so direkt zulassen und habe mir überlegt, ob ich einen openVPN Server direkt auf demselben
Server installieren könnte.

Ist mir klar, dass das keine saubere Lösung ist, wollte für meine Testumgebung aber keine zweite (Linux) VM mit openVPN aufsetzen,
die mir MS natürlich zusätzlich zusätzlich berechnen würde.

Ich bräuchte Eure Meinung, ob openVPN auf derselben Maschine laufen könnte und ob ich mir dadurch ein Sicherheitsleck
"einkaufen" würde.

Beste Grüße
Benson

Content-Key: 604209

Url: https://administrator.de/contentid/604209

Ausgedruckt am: 29.06.2022 um 11:06 Uhr

Mitglied: aqui
Lösung aqui 13.09.2020 aktualisiert um 10:23:20 Uhr
Goto Top
Ja, natürlich kann es das und es ist natürlich kein Sicherheitsleck. Ganz im Gegenteil, denn RDP gilt mit seiner sehr schwachen Verschlüsselung als nicht sicher. Du tust also gut daran das abzusichern.
Aller weiteren OVPN Infos findest du HIER:
Mitglied: bensonhedges
bensonhedges 13.09.2020 um 10:37:25 Uhr
Goto Top
Vielen Dank. Mittlerweile habe ich erfolgreich openVPN mit static key eingerichtet. RDP durch den Tunnel funktioniert.

Eine Herausforderung habe ich noch. Ich möchte, dass der Server nach einem Neustart automatisch die VPN Verbindung aufbaut. Geht via —connect server.ovpn per Aufgabenplanung.
Irgendwie zieht er aber die Config nicht.
Daran bastle ich heute noch.

Gruß,
Benson
Mitglied: aqui
Lösung aqui 13.09.2020 aktualisiert um 11:04:45 Uhr
Goto Top
Mitglied: GrueneSosseMitSpeck
Lösung GrueneSosseMitSpeck 13.09.2020 um 23:53:05 Uhr
Goto Top
Das Netzwerkinterface von Windows sollte man nicht direkt ins Internet stellen. Worst practice. Egal ob da ein OpenVPN Listener läuft oder der für RDP. Wenn es denn unbedinbt sein muß über einen Reverse Proxy (und der kostet defintiv extra)

RDP von Windows 2016 ist nach ein paar Tagen über Zerodays gehackt, egal wie stark das Kennwort ist (hatte ich mal) und ich wage mal zu behaupten, daß es um die Robistheit des Windows NEtzwerkadapters auch nicht allzuweit bestellt ist.

Und warum so kompliziert wenn es auch einfach geht... Azure offeriert unter anderem Point-to-Point VPN und Point-to-Site VPN , da gibts sogar einen Konfigurator für, der einem für den Client-PC gleich ein Icon auf den Bildschirm heftet.
Mitglied: bensonhedges
bensonhedges 14.09.2020 um 12:33:19 Uhr
Goto Top
Auch wenn es eine Testumgebung ist, eine Sicherheitslücke wollte ich vermeiden.

Site to Site VPN bekomme ich wegen meiner AVM Fritz!Box und dyn. IP nicht hin.


Daher werde ich den Ratschlag umsetzen und eine Ubuntu VM mit openVPN (möchte gerne openVPN verwenden) installieren. Darüber werde ich den Zugriff auf die VM realisieren.

Alternativ teste ich auf der Ubuntu Maschine einen Reverse Proxy, wenn es möglich ist von außen via 443 zu kommen und dann intern via RDP auf die VM zu verbinden.
Hast Du ggf. einen Link für mich, den Du empfehlen kannst?

Danke,
Benson
Mitglied: GrueneSosseMitSpeck
GrueneSosseMitSpeck 14.09.2020 um 16:14:12 Uhr
Goto Top
ich glaub du hast da was mißverstanden, Site-to-Site würde nur mit festen IP Addressen auf deiner Seite gehen, das dürfte schon mal am Provider scheitern. Aber ist auch nicht nötig.

Ich meinte Point to Site wo dein Rechner als Client (Point) die VPN Verbinudng zu einem Endpunkt in Azure aufbaut (Site) und das wird als VPN Gatway zur Verfügung gestellt.

Bei mir hat die Point to Site Variante mit allem funktioniert, was es so an Internetzugängen gibt, nur nicht wenn ich im Homeoffice schon im Firmen-VPN eingewählt bin.

Aber OpenVPN wäre auch eine Alternative... dafür gibts im Azure sogar Vorlangen-VM s im Marketplace. Wäre aber sichereer wenn man das selber baut denn man weiß ja nie was in so einerVorlangen-VM drin ist, selbst Microsoft distanziiert sich davon.
Mitglied: bensonhedges
bensonhedges 14.09.2020 um 16:24:52 Uhr
Goto Top
danke für die Hinweise! Ich bin gerade dabei, OpenVPN als VM selbst zu bauen, anhand dieses Artikels:

https://www.digitalocean.com/community/tutorials/how-to-set-up-and-confi ...

Wenn es klappt, gebe ich eine Rückmeldung.
Würde allerdings parallel auch gerne die Reverse Proxy Thematik angehen (443 Proxy nach 3389 intern).
Hab dazu noch nichts spannendes gefunden.
Mitglied: aqui
aqui 14.09.2020 aktualisiert um 16:30:56 Uhr
Goto Top
Site-to-Site würde nur mit festen IP Addressen auf deiner Seite gehen
Jein. DDNS würde auch klappen. Schlimmer wären DS-Lite Anschlüsse. Da gehts nicht, oder eben nur mit IPv6.
OpenVPN als VM selbst zu bauen, anhand dieses Artikels:
Oder auch hier steht wie es geht:
https://administrator.de/tutorial/merkzettel-vpn-installation-openvpn-56 ...
gerne die Reverse Proxy Thematik angehen
https://containo.us/traefik/
oder Nginx Reverse Proxy.
Mitglied: bensonhedges
bensonhedges 17.09.2020 um 12:20:54 Uhr
Goto Top
Hallo zusammen,

kurze Rückmeldung.
Ich habe jetzt anhand der Anleitungen eine CA-VM (Ubuntu) und eine OpenVPN-VM (Ubuntu) in Azure aufgesetzt und konfiguriert.

Eine Verbindung zum RDP-Rechner vm-prod-001 (Win10Pro) sollte dann im Anschluss durch den VPN-Tunnel ermöglicht werden.

Ich bin soweit gekommen, dass ein openVPN Client die Verbindung zum OpenVPN-Server erfolgreich aufbauen kann (Hurra!).
Ein Ping zum OpenVPN-Server 10.8.0.1 geht durch.

Ich bekomme aber keine Verbindung zum RDP-Server oder auch zum CA-Server (beide ebenfalls im gleichen 10.0.0.0/24er Netz).

Route ADD 10.0.0.0 MASK 255.255.255.0 10.8.0.5 ist in der server.conf gesetzt (sieht man auch im Log).

Umgebung:

OpenVPN Server
Public IP: 123.123.123.123
Private IP: 10.0.0.5

RDP-Maschine
Private IP: 10.0.0.4

VPN-Netz: 10.8.0.0/255.255.252
Gateway: 10.8.0.1
tun0 (VPN-Adapter des OpenVPN Servers): 10.8.0.6

VPN-Client-Netz: 192.168.2.0/254
Router (AVM 7590): 192.168.2.251





Hier das Client-Log der OpenVPN-Verbindung:


Liegt es vielleicht an der Ubuntu-Firewall?


Danke für jeden Tipp in die richtige Richtung :) face-smile

LG
Benson
Mitglied: bensonhedges
bensonhedges 17.09.2020 aktualisiert um 12:31:53 Uhr
Goto Top
Ich habe es selbst lösen können. Meine Vermutung war wohl richtig, dass es an der Firewall liegen muss:


Kann mir das jemand erklären, warum ich das VPN-Netz maskieren muss? Ich will ja eigentlich ins 10.0.0.0/24er-Netz,
was ja jetzt auch funktioniert....
Mitglied: aqui
aqui 17.09.2020 aktualisiert um 13:33:01 Uhr
Goto Top
Kann mir das jemand erklären, warum ich das VPN-Netz maskieren muss?
Das ist auch kompletter Unsinn, denn die internen Netze NATet (IP Adress Translation) man natürlich niemals. Genau das hast du aber gemacht (Maquerading= NAT). Das geht immer mit einem massiven Performance Verlust einher bzw. kann gravierende Nachteile mit Fragmentierungen nach sich ziehen. Kein Netzwerker macht so einen Unsinn denn intern besteht logischerweise niemals Zwang zu NATen.
Außerdem mit der dann aktiven NAT Firewall machst du kein transparentes Routing mehr. Dein Routing ist also eine Einbahnstraße.
Vergiss den Unsinn also.

Was du falsch gemacht hast hat 2 Gründe:
  • a.) Du hast vergessen IP Forwarding zu aktivieren auf dem Server
  • b.) Du hast vergessen eine statische Route auf das interne OVPN IP Netz im Router einzutragen sofern ein externer Internet Router im Spiel ist.
Das hiesige OVPN Tutorial weist an mehreren Stellen explizit auf diese beiden wichtigen Punkte hin !!
https://administrator.de/tutorial/merkzettel-vpn-installation-openvpn-56 ...
Deine aktuelle "Lösung" ist also mehr als suboptimal...auch wenn es vermeintlich rennt.
Traceroute und Wireshark sind wie immer deine besten Freunde !
Mitglied: bensonhedges
bensonhedges 17.09.2020 um 14:01:37 Uhr
Goto Top
Hallo aqui,

danke Dir für den ausführlichen Kommentar! Natrülich möchte ich, auch wenn es nur eine Testumgebung ist,
openVPN sauber einrichten.

zu a)
IP Forwarding ist auf dem openVPN Server bereits aktiv:

zu b)
Mir ist nicht klar, wo ich die feste Route eintragen soll. Der openVPN-Server ist ja m. E. auch in meinem Falle der Router (Azure).

So sieht die Route vom OpenVPN Server aus:

Und so die des Clients nach dem VPN-Aufbau:


Der Router des Clients ist eine Fritz!Box mit der IP 192.168.2.251.
Ich denke aber, dass hier keine Route eingetragen werden muss, da es ja keine Site-to-Site Kopplung ist.

VG
Benson
Mitglied: aqui
aqui 17.09.2020 aktualisiert um 17:00:18 Uhr
Goto Top
Mir ist nicht klar, wo ich die feste Route eintragen soll. Der openVPN-Server ist ja m. E. auch in meinem Falle der Router (Azure).
Das ist richtig ! Wenn der OVPN Server dein Tunnelendpunkt mit der öffentlichen IP ist dann ist dem auch so. Dann benötigst du dort natürlich keine extra statische Route, denn der Server "kennt" diese beiden IP Netz ja da sie direkt an ihm angeschlossen sind.
Du hast es ja schon richtig gemacht und bei aktivem OVPN Client ein route print in der Eingabeaufforderung (Windows) eingegeben. Dort sollte dann jeweils ein Eintrag für das interne OpenVPN Netz vorhanden sein und auch einer für dein lokales LAN !
Beides ist bei dir der Fall, folglich werden aus beide Netze in den Tunnel geroutet
Ich denke aber, dass hier keine Route eingetragen werden muss, da es ja keine Site-to-Site Kopplung ist.
Auch das ist richtig !
OVPN technisch hast du soweit alles richtig gemacht.

Es ist also stark zu vermuten, sofern ein Winblows OS als Server im Spiel ist, fast immer bei Winblows die lokale Firewall des Servers zuschlägt. Da die Windows eigene Auto Erkennung des Tunnelnetzes durch das fehlende Gateway immer fehlschlägt deklariert die lokale Firewall dieses Netz immer als "Public" und blockt somit jeglichen Zugriff. Typische Winblows Firewall Problematik.
Was du aber immer in den Firewall mit erweiterer Einstellung Optionen entsprechend auf ein Private Profil anpassen kannst mit einem Mausklick, was das Problem dann sofort löst.
Alternativ kannst du die FW auch entsprechend manuell customizen nach deinen Sicherheitsvorgaben.
Es kann final nur noch ein Firewall Problem sein !