Wenn du befähigt bist, einen Windows Server oder allgemein Windows handlungssicher zu administrieren, dann würde diese Frage nicht existieren.
Ich meine das nicht böse, aber hier herrscht eher so ein "Gentlemen Agreement", bei sowas nur bedingt Hilfestellung zu leisten, um nicht einen kompromittierbaren Server produktiv ins Netz zu verfrachten....weil es im Rahmen IT-Sicherheit dann auch noch an 78 anderen Stellen klemmt.
Nichts für ungut.
Muss der Support machen, hatte ich letzten Monat gerade erst....hat aber gedauert 
Wobei das "Developer" mMn etwas irreführend ist.
In der FAQ wird Anfangs von Developern für Testing, Demos und Small Production Use gesprochen.
Im weiteren Verlauf heißt es dann:
The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities.
Ist doch einwandfrei.Kenne auch einige, die das so nutzen. Ist wohl tatsächlich sehr stressfrei mit RedHat in dem Punkt.
Zumindest das mit CentOS kann ich in Anteilen nachvollziehen. Ich will gar nicht wissen, wie viele KMU weltweit und sonstige Unternehmen "für lau" RedHat in Form von CentOS genutzt haben....um sich Kosten zu sparen.
Natürlich kommt auch immer das Argument: CentOS in der Testumgebung und RHEL auf produktiver Ebene.....die Wahrheit wird bei unzähligen gewesen sein: CentOS only.
Für den Privatgebrauch hat RedHat das "no-cost developer program" seit geraumer Zeit.
Damit kann ich 16 (Sechzehn) RHEL-Installationen "egal wie" (Bare Metal, VM) nutzen, kostenfrei...und mit Zugriff auf deren Support-Portal.
Das fand ich dann doch einen netten Move.
Das Windows Admins "historisch" immer noch sehr auf RDP fixiert sind....lass ich mir eingehen.
Aber ein Linux Server mit GUI ist schon hart... 
Gilt ja tatsächlich auch in Sachen IT-Sicherheit als Best Practice, die Windows Server als Core ohne GUI zu installieren.
Die Administration erfolgt dann bspw. per RSAT, WAC (Windows Administration Center) oder eben Remote per Powershell/SSH (wie von dir genannt).
RDP gilt ja nur noch per LAPS als absolut letzte Zugriffsmöglichkeit, die in Betracht gezogen werden sollte....wenn Windows Server mit GUI installiert wurden.
Aber die Administration eines Windows Servers rein über Shell ist für viele Windows Admins das selbe, wie das erste Mal in der Linux Shell....da RDP zu bequem ist^^, da fehlt es massiv an Handlungssicherheit (wovon ich mich selbst nicht ausschließe).
Servercontrolpanel (SCP) --- <Your Server> --- Network section
Aber Netcup bewirbt den Notfall-Support als 24/7-Erreichbarkeit parallel neben dem regulären Support und eben nicht "1st-Level wenn außerhalb der Geschäftszeiten"
D.h. wenn ich ein Problem habe und 40€/15 Minuten zahle....dann muss ich doch auch selbst an einem Dienstag Nachmittag um 13:00 von diesem Support mehr erwarten können, als wenn ich den regulären anrufe!?...wenn ich etwas als einen Notfall bewerte (bspw. Cloud-VLAN geht nicht mehr und ich brauchs dringend).
Daher sollte dann dort mMn schon ein Team sitzen, was in den jeweiligen Fachbereichen handlungsfähig ist....auch neben dem parallelen und regulären Support.
Weil wenn der Notfall-Support nicht deutlichst mehr machen kann als der reguläre...dann braucht man da auch keine 24/7-Erreichbarkeit, sondern definiert das als "außerhalb der Geschäftszeiten".
Aber nur meine Meinung
Stichwort "meckern"....welche Kompetenzen hat eigentlich der Notfall-Support, hat hier jmd. Erfahrungswerte?
Ich hatte 2x Kontakt und immer hieß es "Kann ich nichts machen".
Einmal hatte ich mich im Rahmen eines Domainumzugs vom CCP ausgesperrt (temporäre Verdummung), weil die hinterlegte Mail-Adresse auf dieser Domain war.
Beim Umzug vom vorherigen zu Netcup war die Mailfunktionalität dann natürlich down.
Der Notfall-Support hat gem. Aussage keinen Zugriff auf die Stammdaten und kann nix machen...
Und zu meiner Frage wegen einem Nicht-Funktionalen IPv6-Subnet konnte man auch nix machen.
Ich bin eigentlich davon ausgegangen, dass ein Notfall-Support alle Kernkompetenzen (Server, Hosting, Netzwerke,...) bereitstellt (auch ggf. mit mehreren Einzelpersonen aus den Fachbereichen)....dem scheint aber nicht so.
Notfälle können ja durchaus komplex sein, da erwarte ich dann für 40€/15 Minuten aber geballte Fachkompetenz.
(Mir wurde natürlich nichts berechnet, weil handlungsunfähig)
Kann durchaus sein, dass aufgrund der Masse an Tickets (die es wohl derzeit gibt), man die Tickets einfach nur möglichst abfrühstücken will.
D.h. mit dieser Antwort an dich (ohne sich im Detail damit zu beschäftigen) ist das Ticket erstmal "aus den Füßen"...Next.
Das hängt aber natürlich immer vom Individuum ab, was die Dinger gerade bearbeitet.
Ich glaube die haben Probleme mit dem Netzwerk.
CCP macht beim Aufruf Probleme
SCP macht Probleme
Server gehen Offline/Rebooten
(Nodes im Rahmen eines HA-Clusters sind ja.i.d.R. über Aktivkomponenten redundant verkabelt)
Usw.
Auch mein zusätzliches IPv6 Subnetz war tot....dann ging es mal ein paar Minuten, dann wieder nicht. Seit gestern Abend geht es ohne meine Zutun bis heute plötzlich wieder einwandfrei.
Wir hatten das bei uns im Betrieb auch einmal, als der Fachbereich für Netzwerke eine Fehlkonfig ausgerollt hat, das hat sich bis in die Cluster reinskaliert.
Aber alles Glaskugel
Es gibt viele Anbieter, die auf Wunsch die Sperrfrist deaktivieren (bspw. der große Blaue mit den 5 Buchstaben).
Kann Netcup das auch? Da habe ich keine Erfahrungswerte.
Ohne Witz....ich bin vor kurzem erst mit Sack und Pack wieder zu Netcup umgezogen.
Supportdauer, jetzt die Grütze mit CCP/SCP, dann -wie hier bereits erwähnt - mein nicht funktionales IPv6 Subnetz....da krieg ich leider schon fast wieder Bock nochmal umzuziehen 
Netcup hat bei mir da mittlerweile den Status "Reliable" verloren....das war gefühlt früher deutlich besser oder zumindest nicht so auffällig krebelig^^
Aha....das erklärt vielleicht mein Problem.
Vor ca. 3 Stunden habe ich versucht im SCP ein zusätzliches IPv6 Subnetz auf einen Root Server aufzuschalten. Jedes Mal wenn ich die Aufschaltung übernommen habe, hat er sich einige Sekunden einen abgerödelt und mir dann einen nackten Netzwerkabschnitt im SCP angezeigt (keine Inhalte, nur die blanke Hintergrundfarbe).
Erst nach dem ca. 10. Versuch hat es dann im SCP geklappt.....aber es funktioniert nicht, er hängt gem. Traceroute direkt beim ersten Hop auf einer IPv6 die wohl zu Netcup gehört.
Es geht also nix raus....
Und da der Support ja leider momentan länger für alles braucht, sagt mir meine Glaskugel: Das dauert jetzt....
Hmm, ich finde den Punkt mit den Zusatzprodukten wie vLan ja echt plausibel, aber wenn mir jemand erzählt, dass er den Standort wegen 3ms mehr Laufzeit wechseln möchte, provoziert das bei mir schon die Frage, was man da so Zeitkritisches auf einer VPS 500 laufen lässt? Steuert da jemand mit Marschflugkörper oder läuft da ein Gravitationswellenlaser oder sowas? Ich mein, wer weiß, aber ich würde doch zugegeben neugierig, wenn ich das im Support als Grund für eine Reklamation lesen würde.
Er hat Nürnberg bestellt und will Nürnberg haben....ob das jetzt 1ms oder 30ms sind.
The Netcup support will usually not support your problem, because Netcup is "only" deploying the virtual machine (runtime environment) and is not responsible for anything what you are doing in it.
And "cannot login via ssh" is OS-based and not VM-based....so the responsibility ist on your side.
Also another user in this thread tried to reproduce your problem....but it worked.
It should be a misconfiguration on your side or you are doing it still wrong... 
Das kommt darauf an wie scharf du das Ganze betreiben willst, zumal (zumindest ich) deine Systeme und deren Kommunikationsbeziehungen nicht kenne^^
Also zunächst rein generisch:
Ein Anfang wäre es, der/die Firewall(s) auf "DENY incoming" zu setzen (keine eingehenden Verbindungen erlaubt). Per Whistelisting dann die eigenen IPs + nötige Ports,etc. erlauben.
Im Ergebnis lässt dein Server nun keine eingehenden Kommunikationsbezeihungen außer von den erlaubten IPs und zu den konfigurierten Ports zu.
Ausgehend kann man das Ganze natürlich auch beliebig komplex konfigurieren, aber ein "ALLOW outgoing" (ausgehende Verbindungen vom Server sind erlaubt) sollte ahS erstmal absolut OK sein.
Im Gesamtergebnis können nur noch deine eigenen IPs über von dir definierte Ports mit dem Server sprechen. Ausgehend würden hier zunächst keine Einschränkungen herrschen, womit auch ein "apt update",etc. weiterhin as usual funktioniert.
Wenn dein "apt update" eine Verbindung zu bspw. den Debian-Repo-Servern aufbaut, ist die anschließende und zugehörige eingehende Verbindung zulässig. Hier muss also nichts zusätzlich bei eingehenden Verbindungen konfiguriert werden.
Das ist jetzt aber (wie genannt) absolut generisch ohne Round-About...würde aber so funktionieren.
-----------------------
Ich betreibe bspw. diverse Services in einem "Backend". D.h. hier befinden sich mehrere Services innerhalb eines privaten IPv4-Netzes und einem zusätzlichen IPv6-Subnetz (ich nutze Proxmox, daher das zusätzliche Subnetz...sonst ist das bei Netcup mit IPv6 leider nur ein rumgesch*sse)
Als "Gatekeeper" terminieren alle eingehenden Verbindungen immer auf einem vorgeschalteten Reverse-Proxy (nginx), der das Ganze dann in mein "Backend" zum entsprechenden Service weiterschubst. Meine Services selber lassen Ausnahmslos nur eingehenden IP-Verkehr aus diesem genannten, privaten IPv4-Netz sowie nur meinem eigenem zusätzlichen IPv6-Subnetz zu. D.h. von "außen" kommt keiner an die Services.
Auch alle meine DNS-Records terminieren alle auf dem Reverse-Proxy.
Bildlich gesehen eine "Bubble" mit allen meinen Services und einem Reverse-Proxy obendrauf. Intern können die miteinander sprechen wie sie wollen...von außen geht`s nur über den Revers-Proxy rein.
Das Ganze könnte man eingehend am Reverse-Proxy jetzt natürlich (wie in deiner Idee) noch auf bestimmte IPs festnageln..
Da gibt es auch andere Lösungen, aber in meinem Fall war das für mich die zweckmäßigste.
Der Fehler lag daran, dass du versucht hast Windows auf Laufwerk 0/Partition 1 (System) zu installieren....das geht grundsätzlich nicht an der Stelle...wäre mit dem Speicherplatz auch etwas "dünn" wenn es auf diesem Typ der Partition installierbar wäre.
In deinem Fall geht das bei deinem Setting nur auf der Primärpartition (Laufwerk 0/Partition 3).....die hättest du nur anklicken brauchen und dann installieren....
EDIT: Das sagt dir auch die Fehlermeldung auf deinem Screenshot
Und entschuldigt die Edits, ist schon so spät in der Nacht^^
Root-Server:
Teilen ist doof! Oder?
das in Kombination mit CGNAT find ich irgendwie kompletten Unsinn ...
Macht auch die Telekom im Mobilfunknetz über den APN "internet.telekom"....Dual-Stack, aber IPv4 ist CGNAT.
Der APN wurde jetzt aber vor einiger Zeit abgelöst durch "internet.v6.telekom", dort ist jetzt IPv6-only per 464XLAT.
Dual-Stack mit CGNAT ist seltsam, aber nicht zwangsweise ungewöhnlich
