Beiträge von gunnarh

Die Aktivierbarkeit der Lizenz als Indikator für Legalität zu betrachten ist nicht zweckmäßig.

Hier ein Artikel eines Microsoft Österreich Verantwortlichen zu diesem Thema: https://windowsblog.at/2016/09/27/win…nal-um-390-eur/

Mir ist übrigens keine Möglichkeit bekannt, wie man ein Windows 10 in einer VM eines IaaS Anbieters korrekt lizenziert betreiben könnte. Konkret verstößt man da nämlich gegen die PUR (Product Use Rights) (siehe https://www.microsoft.com/en-us/licensin…ensing/products) die in Bezug auf Desktop-Betriebssysteme folgendes besagen:

Zitat

Der Kunde ist je erworbener Lizenz berechtigt, eine Kopie der Software auf einem Lizenzierten Gerät oder innerhalb eines lokalen virtuellen Hardwaresystems auf einem Lizenzierten Gerät zu installieren.

Die Lizenz in einer VM in einem Rechenzentrum zu installieren ist nicht "lokal virtuell". Und auch die anderen Spielarten die erläutert werden (Remote-Verwendung, typische VDI Szenarien) sind meines erachtens in dieser Konstellation nicht erfüllt. Studentenlizenzen schließen übrigens gar keine Virtualisierungsrechte mit ein (siehe Anhang H). Meiner Auffassung nach wäre die einzig korrekte Lizenzierungsmöglichkeit ein Microsoft Services Provider License Agreement (SPLA) - das müsste aber der Service-Provider (in diesem Fall Netcup) anbieten.

janxb - die Foren-Regeln (die ich jetzt ad-hoc hier nirgends finden konnte?) untersagen meines Wissens das Diskutieren von Konkurenz-Angeboten hier in diesem Forum. Dass das ein mehrfaches des Preises von Netcup kostet ist korrekt, allerdings nicht 3-stellig, eine Single-Core-VM geht sich auch um ca. 40-50 Euro pro Monat aus, und wie gesagt, da ist die Lizenzierung mit dabei - und eine korrekt lizenzierte Windows Server VM kostet mindestens einen höheren dreistelligen Einmal-Betrag, wenn Client-Access-Lizenzen noch dazukommen auch deutlich vierstellig. Das relativiert dann die laufenden Kosten doch wieder erheblich.

Hätte ich diese Anforderung würde ich - auch wenn Netcup dies in seinem Forum hier vermutlich nicht gerne hört - zu einem anderen Anbieter raten. Der Hersteller von Windows kann in seinem hauseigenen Cloud-Dienst eine Installierbarkeit mittels weniger Mausklicks anbieten, die Betriebssystem-Lizenz ist im Compute-Preis gleich inklusive und eine Firewall vor der Maschine ist auch schon mit dabei.

Wie lautet Deine Frage?

Dein Server kann ganz offenkundig keine der konfigurierten Paketquellen erreichen.

Die Namensauflösung klappt scheinbar noch korrekt, der Zugriff aber nicht.

Was hast Du schon geprüft? Klappt ein manueller Zugriff mit Lynx o.ä. oder wie kommt die Diagnose wonach "apt-update" ein Problem hätte zustande? Ich sehe ohne weitere Details eher ein Netzwerk-Problem (z.B. kein Default-Gateway konfiguriert o.ä.).

Nachdem ich das vLAN derzeit nicht produktiv benötige werde ich wegen der (derzeit) bescheidenen Performance nicht nachstochern - aber eventuell hängt die Performance ja davon ab wie "nahe" die Maschinen beinanderstehen (im besten Fall vielleicht sogar am selben Host liegen, oder am selben Switch hängen).

Mein Performance-Test des Cloud-vLAN Free mit iPerf zeigt mir nur einen eher enttäuschenden Throughput von 15MBit/sec.

------------------------------------------------------------
Client connecting to 192.168.200.100, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.200 port 36589 connected with 192.168.200.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  18.8 MBytes  15.4 Mbits/sec

Fein, dass meine vorgeschlagene socat Lösung den Zweck nun erfüllt.

Betreffend der Aussage:

Zitat

Wenn auf der externen Arbeitsstation ein VPN-Client läuft und sich mit dem Server verbindet, bekommt er eine IP aus demselben Netz.

Wenn die zugreifenden Clients einen VPN-Client nutzen könnten, dann bräuchte man überhaupt kein DNAT, sondern Windows-Server und Clients könnten direkt miteinander kommunizieren. Das war aber in der ursprünglich diskutierten Variante keine Option und im weiteren Diskussionsverlauf explizit ausgeschlossen.

mainziman Die Route die der VPN-Client am Windows-Server automatisch konfiguriert ist lediglich eine für das 10.8.0.0/24 Netz. Durch das DNAT am Linux-VPN-Server ändert sich die Source-IP-Adresse nicht. Aus Sicht des Windows-Servers kommt da eine Verbindung mit einer öffentlichen IPv4 Source-Adresse daher. Wenn er auf diese antworten möchte, dann geht das nicht durch die 10.8.0.0/24er Route zum Linux VPN-Server zurück sondern geht über die öffentliche Internet-Anbindung direkt hinaus ins Web (mit unerwarteter Source-IP-Adresse des Windows-Servers, nämlich seine im Internet vom Carrier Grade Nat verwendete Adresse). So wird das aber nichts, denn selbst wenn diese Pakete das Ziel erreichen sollten werden sie dort mangels Zuordenbarkeit zu einer bestehenden IP-Verbindung verworfen.

Ich sehe daher mehrere Lösungsmöglichkeiten:

a) nicht nur DNAT sondern auch SNAT am VPN-Linux-Server

b) viel einfacher gleich wie von mir bereits erwähnt mit "socat" arbeiten und die Verbindung am Linux-Server terminieren.

Eine eingehende TCP-Verbindung, die vom Linux-VPN-Server nach 10.8.0.15:29422 mittels DNAT weitergeroutet wird scheint am Windows-Server dann mit Source-IP-Adresse des zugreifenden Senders auf.

Also SrcIP:SrcPort -> Dest-IP:DestPort mit DNAT weiter nach FinalDest-IP:DestPort

Der Windows-Server wird Antworten nach SrcIP:SrcPort

SrcIP ist variabel, SrcPort ist variabel

Mit einer statischen Rück-Route ist da also nichts zu machen. Man muss diese Verbindung beim Eingang taggen und so zurückrouten - mit IPTables kein Problem, aber wie man das unter Windows ad-hoc tun würde müsste man erst recherchieren.

Die Tipps von H6G betreffend Rückroute sind korrekt. Aber das wird immer noch nicht reichen. Denn Du müsstest auch auf dem Windows-Server dafür sorgen, dass IP-Pakete diese Verbindungen betreffend über das VPN zurück geroutet werden. Ich weiß jetzt ad-hoc nicht, wie ich das unter Windows geschickt realisieren würde.

Ich würde daher einen anderen Ansatz wählen. Das VPN das Du Dir eingerichtet hast passt schon so - aber das Fowarding würde ich in diesem Fall nicht mittels Destination-NAT / IPTables machen, sondern ich würde ein Tool wie z.B. socat verwenden um einen Listening-Port zu öffnen und an den internen Server weiterzuleiten.

socat -d -ly TCP4-LISTEN:29422,bind=0.0.0.0,fork,su=nobody TCP:10.8.0.15:29422

Ein Reverse-Proxy wäre hier das Mittel der Wahl, der könnte auch die SSL-Terminierung vornehmen.

Die Microsoft Windows Produkt-Aktivierung ist insofern "Black-Magic", als Microsoft nicht offiziell bekanntgibt, wie die Berechnung der Prüfsummen und die zulässigen Abweichungen / Tresholds konkret wirken. Microsoft ändert diese Metriken auch laufend, um unerwünschte Re-Aktivierung nach regulärem Update/Aufrüstung zu vermeiden, und dennoch den Transfer des Systems auf andere Hardware ohne Neu-Aktivierung zu unterbinden.

Folgende Hardware-Eigenschaften gehen (soweit bekannt) in die Prüfung mit ein:

• System-Informationen aus den DMI-Daten (System-Hersteller, Seriennummer etc...)
• Lizenz-Informationen aus den ACPI-Tabellen (Software Licensing Description Table) des BIOS - insbesondere bei OEM-Lizenzen!
• Grafikkarte
• SCSI, SAS, IDE, SATA Adapter
• MAC-Adresse des Netzwerkadapters
• Hauptspeicher
• Processor Type und Serial Number
• Harddisk sowie Volume-SerialNumber

Nur "interne" Geräte werden in die Prüfung mit einbezogen, USB-Geräte und externe Peripherie (z.B. in Docking-Stations) wird nicht berücksichtigt. Ziel von Microsoft ist wie gesagt einerseits typische Hardware-Upgrades wie Hauptspeicher-Erweiterung, zusätzliche Disk ergänzen, Grafikkarte austauschen, ... zuzulassen, aber dennoch zu verhindern, dass das System 1:1 auf ein anderes (ähnliches) System kopiert wird ohne eine ReAktivierung zu erfordern. Der Algorithmus ist - ohne ihn zu kennen - nicht wirklich empirisch nachvollziehbar.

Dass beim Transfer eines Image von einem virtuellen System auf ein anderes die ReAktivierung erfahrungsgemäß sehr konsequent nötig ist, legt den Verdacht nahe, dass Microsoft das durchaus bewusst so forciert. Je nach Virtualisierungsprodukt kann man all diese geprüften Merkmale mehr oder weniger gut "verstecken" bzw. am Zielsystem gleichartig emulieren. Dass das OS auf virtueller Hardware läuft ist ja einfach prüfbar, erfahrungsgemäß reicht auf virtualisierten Systemen bereits der Wechsel der Netzwerk-MAC-Adresse und/oder der CPU aus um eine ReAktivierung zu benötigen (selbst wenn alle anderen Eigenschaften gleich bleiben). Wenn man nicht mit virtuellen CPUs arbeitet, sondern die nativen Virtualisierungseigenschaften möglichst effizient nutzen möchte und so die physischen CPUs durchreicht scheitert man hier erfahrungsgemäß und es kommt jedenfalls zu einer Neu-Aktivierung.

Im Unternehmensumfeld stellt das typischerweise kein Problem dar, da dort die Systeme mittels KeyManagementServices (KMS) und Volumenslizenzen automatisch reaktiviert werden. Auch in der Azure-Cloud muss man sich nicht darum kümmern, da dort KMS-Services bereitstehen.

Eine 1:1 Kopie die man lediglich erstellt um mit der Kopie z.B. ein Softwareupdate zu testen, bevor man dies am Produktivsystem anwendet würde ich einfach vorübergehend ohne Aktivierung nutzen (es ist innerhalb der Grace-Periode mit keinen Einschränkungen zu rechnen).

Ein Verschieben einer VM auf neue Hardware löst zwar eventuell eine Re-Aktivierung aus, diese kann und darf jedoch durchgeführt werden da es sich ja nicht um ein dupliziertes sondern verschobenes System handelt. Nötigenfalls (wenn die online-Aktivierung verweigert wird) muss man eben telefonisch reaktivieren und eventuell auch mit einem "Menschen" an der Aktivierungshotline sprechen, der sich das Szenario schildern lässt und bei Glaubwürdigkeit beurteilt, dass dies zulässig ist.

Nur eine Interessensfrage: Welche Linux-Distribution wird hier eingesetzt?

Ich hätte jetzt ad-hoc nicht erwartet, dass es eine noch mit Security-Updates versorgte Linux-Distribution gibt, in der ein derart alter Apache+OpenSSL im Einsatz ist, welcher die Direktive SSLUseStapling nicht kennt.

Betreffend der Chain: Die vom WebServer zu sendende Chain enthält nur das bzw. die Intermediate-Zertifikate. Das Root-Zertifikat selbst ist aber eigentlich NICHT im Chain-File einzufügen, denn das Root-Zertifikat ist ja im Stammzertifikatsspeicher des zugreifenden Clients vorhanden. Bei SSL-Tests wie z.B. Quallys SSL Labs führt eine solche (Fehl-)Konfiguration daher zum Hinweis "Chain issues - Contains anchor".

Die apache2.conf ist bei allen mir bekannten Distributionen keine zu ändernde Konfigurationsdatei.

Die vHosts sind üblicherweise im Verzeichnis sites-enabled zu finden.

Dort im betreffenden vHost ist dann im vHost beim betreffenden Directory-Eintrag die Direktive zu setzen.

Doku: https://httpd.apache.org/docs/2.4/de/mo…l#allowoverride

Zitat

Im obigen Beispiel erzeugen alle Direktiven einen internal server error (Anm.d.Ü.: Server-interner Fehler), die weder der Gruppe AuthConfig noch der Gruppe Indexes angehören.

Kann Dein Problem auf meinen vServern nicht nachvollziehen.

root@nc:~# nslookup example.com 46.38.225.230
Server:         46.38.225.230
Address:        46.38.225.230#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Da ich hier auf meine Pi-mal-Daumen Schätzung mehrfach angesprochen wurde vielleicht auch noch meinerseits ein paar Worte.

1. Ich habe keine Ahnung welche Disks zum Einsatz kommen. Alleine die Auswahl der Disks und der konkreten Charge lässt die Kalkulation schon um Zehnerpotenzen auseinander laufen.

2. Ich habe keinen Einblick wie Netcup das Raid baut. Meine Annahme war die schlechtere (zuerst stripen, dann spiegeln). Wenn Netcup zuerst plattenweise spiegelt dann striped, und wenn vielleicht nicht 6 sondern nur 4 Platten für das RAID10 verwendet werden kommt auch gleich ein deutlich anderer (auch besserer) Wert raus.

3. Ob eine Hot-Spare Platte zum Einsatz kommt, oder der diensthabende Techniker einfach bei Alarm des RAID-Systems zügig die Platte manuell ersetzt, ist in Bezug auf die Ausfallswahrscheinlichkeit des Gesamtraidverbundes nur mäßig relevant. Die Zahlen gelten für ein intaktes Raid mit aufrechter Redundanz. Sobald die Redundanz verloren ist, ist Feuer am Dach - dann liegt die Wahrscheinlichkeit eines Ausfalls plötzlich im Prozent- statt Promille-Bereich. Dass starke Aktivität (ReSync) hier zusätzlich stresst ist bekannt. Dass Platten aus der gleichen Tranche mit dem gleichen Lieferweg und gleicher Beanspruchung auch gerne mal zufällig recht zeitnah ausfallen ebenso. Wenn man hier signifikante Verbesserungen möchte, muss man einen RAID Verbund so bauen, dass auch bei Ausfall einer Platte weitere Redundanz noch garantiert vorhanden ist (und nicht nur in manchen Fällen, wie das bei RAID 10 bei einfacher Spiegelung der Fall ist).

Es wurde nach der Wahrscheinlichkeit gefragt, dass ein Hardware-Fehler einen Datenverlust verursacht. Ich habe eine Schätzung abgegeben, die lediglich die Disken des RAID-Verbundes berücksichtigten. Menschliche Fehler (auch am Hostsystem), Fehler des RAID-Controllers selbst etc... blieben unberücksichtigt und sind ebenfalls signifikant.

Meine best guess Kalkulation lautete: Statistisch gesehen fällt je 1000 Hosts pro Jahr ein Raid-Verbund mit Datenverlust aus.

Setzt man andere Zahlen ein, oder baut den Raid-Verbund geringfügig anders, kommt man auf 1 Datenverlust je 100 Hosts oder auch auf 1 Datenverlust je 20000 Hosts. Datenverlust bedeutet dann, dass alle 10/20/50/100 Kunden am Hostsystem betroffen sind.

Defekte Disks die zu tauschen sind, ist sicherlich Tagesgeschäft. Bei 1000 Hosts mit angenommen 6000 Disks sind vermutlich 50-200 Disks pro Jahr wegen Defekt zu tauschen. Also alle 2-3 Tage eine Disk. Das sollte Routine sein.

Die Annual Failure Rates von SSDs und HDDs liegen je nach konkretem Modell und Einsatz meist zwischen 0 und 10% (typischerweise wenn man keinen absoluten Fehlgriff an Disken hat bei 1-3%). Also von 100 Disks im Rechenzentrum werden pro Jahr 3 kaputt. Auch die AFR von SSDs dürfte in dieser Größenordnung liegen.

Wir kennen den RAID-Aufbau der Netcup-Server nicht im Detail. Bei einigen Modellen ist z.B. Raid 10 angegeben, aber über wie viele Disken das Hostsystem verfügt ist für den Kunden so nicht transparent erkennbar. Angenommen es kommen 6 Disks zum Einsatz die jeweils eine AFR von 1% aufweisen, dann lautet die Rechnung meines Erachtens:

Das Stripeset: 3 Disks je 1% = 3% AFR

Der gesamte gespiegelte RAID-Verbund: durch die Spiegelung sollte sich das dann auf 3% ^2 = 0,9 Promille Wahrscheinlichkeit (Ausfall des kompletten RAID-Verbundes) reduzieren.

Oder etwas plastischer: von 1000 Hostsystemen mit so einem Raid10-Verbund fällt im Schnitt einer pro Jahr aus.

Wie immer: glaube keiner Statistik die Du nicht selbst frisiert hast. Ich denke aber die Größenordnung ist nicht ganz verkehrt. Meines Erachtens ist die Wahrscheinlichkeit Datenverlust durch menschliche Fehler (z.B. des Administrators) zu erleiden deutlich höher.

Zitat von [netcup] Kai

Man hat einen Node mit z.b. 10 Kunden mit jeweils einer VM. Jeder Kunde hat andere Zeiträume angekreuzt wodurch es dann quasi keine bzw nur sehr wenige Überschneidungen gibt.

Verstehe. Ich ging davon aus, dass die VMs im Zuge dieser Wartungsmaßnahmen auf andere Hostsysteme verschoben werden. Also: fertig gepatchtes (leeres) Hostsystem steht bereit, VMs werden heruntergefahren, verschoben auf das vorbereitete Hostsystem und dort wieder gestartet. Sobald ein ungepatchter Host leer geräumt ist wird dieser gepatcht und steht dann für die nächsten VMs als Ziel-Host bereit.