ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
LichtiF
Enthusiast
*grins*
Da bin ich froh das wir keinen direkten Internetzugang haben und von außen auch nichts offen ist.
Bei uns müssen die Kollegen die Smartphones haben sich sogar erst per VPN einwählen bevor sie sich ihre Emails abrufen können
Da bin ich froh das wir keinen direkten Internetzugang haben und von außen auch nichts offen ist.
Bei uns müssen die Kollegen die Smartphones haben sich sogar erst per VPN einwählen bevor sie sich ihre Emails abrufen können
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Das mit dem VPN vor den Emails ist da auch so. ABER: Bei einem RZ (also ein gemietetes Rack) das viele KM entfernt ist hat einen Grund warum genau das iLO direkt im Netz hängt: Hängt das System das darauf läuft geht auch kein VPN mehr ins RZ - und damit kommst du dann nicht drauf wenns nicht öffentlich ist.
Aber ich geb ja ehrlich zu, ich bin froh, dass das nicht mein Bier ist und ich mir was anderes gesucht hab
Aber ich geb ja ehrlich zu, ich bin froh, dass das nicht mein Bier ist und ich mir was anderes gesucht hab
Naja, aber hat man nicht meist zwei Systeme im RZ, so das die Möglichkeit besteht auf das zweite System zu gehen, falls das erste ausfällt und von dort aufs ILO zuzugreifen? ;-)
Also ich würde versuchen den physikalischen Zugriff direkt auf den Host zu unterbinden, soweit es eben geht.
Also ich würde versuchen den physikalischen Zugriff direkt auf den Host zu unterbinden, soweit es eben geht.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Aber wenn die Systeme alle keine Öffentliche Anbindung haben (weil die über das System hergestellt wird das auf dem iLO-Rechner läuft? Das System war/ist quasi Frontend/Gateway/Firewall/VPN etc...)
Aber BTT: Soviel zu den public erreichbaren Diensten
Aber BTT: Soviel zu den public erreichbaren Diensten
??
Ich soll mich entscheiden? Du kreidest mir hier an, das man sowas nicht macht und interpretierst selbstständig irgendwelche Sachen rein die gar nicht Teil der Argumentation meinerseits waren... Lies doch, was ich schrieb... Es steht in keinster Weise irgendwo aus meiner Feder, das ich den WebClient direkt public betreibe. Sondern ich schrieb (sogar zweimal!) das ich wenn dann sowas über irgend ein Access Gateway ala TMG schleifen würde. Die erste Ausführung bezogt sich dabei klar ersichtlich auf das Endresultat. Nämlich den Zugriff auf den WebClient via INet. Meine Aussage war: "Vorteil ist aber in jedemfall, man kann den Spaß schön von public nutzen ohne VPN und Co."
Entscheiden muss ich da wohl gar nix... Sondern ich verfolge meine Linie seit Anfang der Diskusion... Wenn du nun erst nach drei Posts damit um die Ecke kommst, das es dir um den WebClient direct public geht, kann ich nix für
Open Source gut und schön... Nur das ganze muss händelbar sein. Ich persönlich halte gewisse Open Source Sachen für durchaus nutzbar, bevorzuge diese sogar, manche Andere hingegen schlicht nicht. Alles eine Frage der Nutzbarkeit und des Aufwandes, den man betreiben muss, um sein Ziel zu erreichen. Und wenn es danach geht, müsste man theoretisch seine Software vollständig selbst Programmieren, denn erst dann kann man auch 100% sicher gehen, das man weis, was man dort gemacht hat. Nur ist der Aufwand eben viel zu hoch, dass dies jeder selbst tun könnte.
Denn ich behaupte, nur die wenigsten Netzwerkadministratoren, oder auch diese, die sich auf Sicherheit der OpenSource Software stürzen -> weil angeblich sicherer!, haben nur im entferntesten überhaupt Ahnung von Programmierung.
Und hier liegt nämlich das Problem. Was bringt dir das Wissen über öffentlich zugänglichen Code, wenn du nicht verstehst, was das Dingens macht? Nein, du versteifst dich in dem Part auf das Wissen Anderer und vertraust vollständig auf diese. Was aber bei Closed Source Software ein Unding sein soll. -> wiederum messen mit zweierlei Maß.
Also bist du Programmierer, der sich den Code jeglicher Open Source Software vollständig durchgesehen hat?
Und wieso verschiedene Zeiten? Der Unterschied liegt wohl schlicht daran, das ich Programmierer bin, und mittlerweile neben Programmiertätigkeiten als Systemadministrator im VMware, Mircosoft und (zu einem kleineren Teil) Linux Umfeld tätig bin. Und genau darauf aufbauend kann ich persönlich den scheinbar schon bedingungslosen Vorzug von Open Source so nicht 100% teilen, vor allem dann nicht, wenn man selbst scheinbar keine Ahnung von Programmierung hat.
Bist du schonmal mit OpenSource Software auf die Nase gefallen? -> ich schon. Und das mehrfach.
Denn Software ist Software, und Open Source enthält genau so Fehler und Sicherheitslücken wie Closed Source. Daran gibts schlicht nix zu rütteln.Aber wenn die Systeme alle keine Öffentliche Anbindung haben (weil die über das System hergestellt wird das auf dem iLO-Rechner läuft? Das System war/ist quasi Frontend/Gateway/Firewall/VPN etc...)
Aber BTT: Soviel zu den public erreichbaren Diensten
Wenn du Ausfallsicherheit willst, stellst du ne geclusterte Lösung da rein...
Optimalerweise über eine doppelte WAN Anbindung (BGP)... Dann hast du auch keine Schmerzen, wenn dir eine Büchse mal um die Ohren fliegt (oder eben runtergefahren wird
)Aber sowas wie den ILO public ohne irgend einen Schutz, macht man ja auch nicht
Beispielsweise ne Firewallfreischaltung gegen User/KW, welche dann die gerade genutzte public IP temporär freischaltet, wäre denkbar. Erst nach Freischaltung greift das NAT auf die ILO IP. Oder wenn direkt public, erst nach Freischaltung lässt die Firewall Zugriffe auf die IP zu. Aber so ganz ohne Schutz? Das ist dann in der Tat etwas leichtsinnig...
Zuletzt bearbeitet:
Ahja...
Es ist HTTPSDu würdest das vCenter WebGUI von aussen direkt ohne VPN erreichbar machen?
Aber nicht in einer produktiven Umgebung, oder?
Bei uns läuft zwar aktuell nicht die produktive Umgebung nach public, meine Testumgebung hatte ich aber von Zuhause aus erreichbar...
Aktuell habe ich aber nicht die Zeit, das ganze mal über unseren TMG zu schieben und zu testen, ob das überhaupt lüppt
Auf diesen schizophrenen Müll habe ich absolut keinen Bock. Mach was du willst.
Erst meckern und dann kein bock auf ne diskusion haben, sollte evtl. vorher überlegt werden.....
Wenn die Tatsachen immer grade so gedreht werden, damit man Recht hat, braucht man nicht diskutieren.
Im Übrigen: wer bist du jetzt?
Mir gefällt deine ParanoiaDas glaubt ihr
Schau dir doch mal das Zitat an. Das widerspricht sich in der Tat.
Nochmal, ich drehe nix... Ich sagte von Anfang an, das der Zugriff potentiell kein Problem ist, weil HTTPS Verschlüsselt... Daraufhin kommst du mit Ausflüchten von wegen, WebClient direkt public usw. keine Zugriffskontrolle und der Sinnhaftigkeit von VPN -> was nirgends auch nur ansatzweise von meiner Seite angesprochen, geschweige denn als irrelevant hingestellt wurde. Wenn ja, bitte zeig mir die Pasage!
Aber ich lasse mich hier bestimmt nicht von dir anmachen und zurechtweisen, weil du irgendwo zu viel reininterpretierst bzw. nicht richtig gelesen hast.
Und mir jetzt hier vorwerfen, ich würde die Argumente verdrehen...
Sorry, aber das ist ziemlich daneben...
Mal ganz davon ab, außer irgendwelchen voreingenommenen Meinungen bzw. pauschalem Geplänkel kannst du ja nichtmal stichhaltige Aussagen bringen, was gegen eine wie auch immer geartete Webveröffentlichung des WebClients selbst spricht... Aber andere belehren wollen, wie "Sicherheit funktioniert".
Wo?
Ich sehe nach wie vor keinen Wiederspruch...
Aber ich lasse mich hier bestimmt nicht von dir anmachen und zurechtweisen, weil du irgendwo zu viel reininterpretierst bzw. nicht richtig gelesen hast.
Und mir jetzt hier vorwerfen, ich würde die Argumente verdrehen...
Sorry, aber das ist ziemlich daneben...Mal ganz davon ab, außer irgendwelchen voreingenommenen Meinungen bzw. pauschalem Geplänkel kannst du ja nichtmal stichhaltige Aussagen bringen, was gegen eine wie auch immer geartete Webveröffentlichung des WebClients selbst spricht... Aber andere belehren wollen, wie "Sicherheit funktioniert".
Wo?
Ich sehe nach wie vor keinen Wiederspruch...
Zuletzt bearbeitet:
Du wolltest wissen, was das Problem an einem öffentlichen Zugang direkt zum vCenter-Web-Interface ist. HTTPS hilft hier genau gar nichts.
Dagegen spricht, dass öffentlicher Zugriff von überall nicht nötig ist. Das reicht. Ganz simples Konzept. Ich muss nicht irgendwelche konkreten Lücken im Webinterface nachweisen, damit diese Aussage richtig wird. Er hat im öffentlichen Netz einfach nichts verloren.
Deine Vergleiche zum VPN, dass man ja so oder so jemandem vertraut, sind auch eher irrelevant. VPNs werden von Grund auf dafür entwickelt, dass sie direkt im Netz hängen und führen in sich den Grundsatz mehrerer Schichten fort. Bei OpenVPN z.B. derart, dass der Traffic ab dem ersten Paket die richtige Signatur tragen muss, da er sonst komplett verworfen wird. Das ist einstellbar und gehört zur "best practice". Der daemon selbst läuft im Userspace, nicht als root und (best practice) in einem abgekapselten chroot. Zusätzlich kann man die syscalls begrenzen, die er ausführen darf bzw. das umgebende System mit allem härten, was einem zur Verfügung steht.
In einem Punkt hast du Recht: OpenSource heißt auf keinen Fall automatisch Qualität oder Fehlerfreiheit. Aber wenigstens kann ich mir zur Not jemanden einkaufen, der sich das überhaupt anschauen _kann_. Diese Möglichkeit besteht bei ClosedSource von vornherein gar nicht. Ja, in gewisser Weise vertraue ich darauf, dass OpenVPN und die IPsec-Implementierungen durch ihre schiere Verbreitung auch unter vielen Augen vorbeigewandert sind. Edit: Einfach aus dem Grund, dass OpenVPN/IPsec extrem begehrte Ziele wären, auch wenn man mit ihnen bei richtigen Installationen immer noch nicht viel anfangen kann. Es gibt aber trotz VPNs noch genügend Leute, die denken, VPN ist jetzt der heilige Gral und alles drumrum braucht man nicht mehr anfassen. </Edit>
Wenn ich mir anschaue, wie die Performance diesbzgl. in der Vergangenheit aussah, habe ich absolut kein Problem, jeden anderen Dienst damit abzusichern, von dem ich erstmal gar nichts bzgl. seiner Sicherheit weiß: Openvpn : Security vulnerabilities Sämtliche Fälle sind entweder durch best-practice vermeidbar (da haben wirs wieder, Management-Interface z.B. nicht öffentlich zugänglich bzw. überhaupt gar nicht erst aktivieren, ist bei einer "betriebsinternen" Nutzung absolut unnötig, also im dem Sinne, dass ich keine Kunden per OpenVPN bediene), betreffen bereits authentifizierte Clients oder sind "nur" ein DoS. Ich wüsste auf Anhieb nicht, ob und wann man jemals einen OpenVPN aus dem Stand übernehmen konnte.
Bei IPsec das gleiche. Läuft zwar im Kernel, aber das key handling läuft im Userspace, d.h. auch hier härtbar, was die Tools hergeben.
Der Vorteil ist auch, dass ich mir _einmal_ ein Tool angucken muss, mit dem ich dann jeden Schickschnack absichere, der in Zukunft daherkommt und nicht jedes Mal von vorne anfange, mich zu fragen, ob ich den Dienst jetzt ins Netz hänge oder nicht. Wird einfach nicht gemacht, kommt hinters VPN und fertig.
Zuletzt bearbeitet:
Ich hab nen virtualisierten Exchange 2013 (auf nem Server 2012) und möchte diesen von Server1 nach Server2 schieben. (Kein VCenter vorhanden, beide ESXi 5 Update 1)
zeroseven hat mir folgende Schritte genannt:
1. Remove VM from Inventory
2. Browse Datastore
3. Download der VM (Ordner)
4. Upload VM auf neuen Datastore
5. Rechte Maustaste auf vmx Datei -> Add to Invenory
6. VM starten
7. Wenn alles läuft, auf dem alten Datastore die VM löschen
Muss ich speziell weils ein Exchange ist auf noch etwas achten?
Danke euch!
zeroseven hat mir folgende Schritte genannt:
1. Remove VM from Inventory
2. Browse Datastore
3. Download der VM (Ordner)
4. Upload VM auf neuen Datastore
5. Rechte Maustaste auf vmx Datei -> Add to Invenory
6. VM starten
7. Wenn alles läuft, auf dem alten Datastore die VM löschen
Muss ich speziell weils ein Exchange ist auf noch etwas achten?
Danke euch!
delicious_cake
Enthusiast
- Mitglied seit
- 07.11.2009
- Beiträge
- 4.920
Nein, keine Besonderheiten.
Nein, wieder falsch... Das stimmt schlicht nicht und war definitiv nicht meine Aussage...
Über die Zwischenstellen, welche die Sicherheit zwischen public WAN und interner IP WebClient VCenter herstellen habe ich mich genau Null ausgelassen im ersten Step. Sondern ich sprach lediglich den Vorteil an, das es machbar wäre, den WebClient public verfügbar zu machen. Erst auf Nachfrage sagte ich, wenn dann würde ich sowas über ein Access Gateway ala TMG/UAG machen, oder über irgend eine andere Form eines SSL Gateways/Reverse Proxys.
Auch das ist viel zu pauschal... Ich bin drauf angewiesen, dass ich von Zuhause aus auf unsere ESX Infrastruktur komme, die Weltweit irgendwo verstreut steht. Einfach weil es mein Job ist diese Systeme zu betreiben/zu betreuen... Und ich kann schlicht und ergreifend nicht überall physisch hinfahren. Ebenso wenig bin ich 24/7 also rund um die Uhr an meinem Arbeitsplatz...
Ein Zugriff von Extern, wie auch immer geartet ist also zwingend Notwendig. Und dabei bietet mir der WebClient nochmal ein Stückweit mehr Flexibilität, denn ich bin nicht zwingend darauf angewiesen, irgendeine VPN Connection aufbauen zu müssen, wie es ohne diesen zwingend notwendig ist. Einfach weil diese auch nicht immer und überall aufbaubar ist, was durchaus bekannt sein dürfte.
Anderes Verfahren bedingt also eine andere Konzeptionierung beim Thema Sicherheit. Nur soweit war ich bei meiner ersten Ausführung noch gar nicht, ihr habt aber dennoch erstmal pauschal resigniert -> ohne das die Umsetzung überhaupt Thema war
und genau das kreide ich hier an. Denn nach wie vor gibt es keine KO Argumente, warum man die Möglichkeiten der Webadministration nicht, wie auch immer umgesetzt, von public aus nutzen soll/kann/darf Denn so oder so entscheidet einzig und allein die Absicherung zwischen Quellsystem über WAN zum Zielsystem über das Thema Sicherheit, denn genau dafür ist dieses System da und nur dafür! Ob sich das Teil nun OpenVPN schimpft, oder TMG/UAG, oder ne Astaro/UTM oder ne Cisco ASA, oder ein Nortel Contivity bzw. Nortel VPN Gateway oder wie auch immer, ebenso ob Open Source oder Closed Source, ob Software Appliance oder Hardware Appliance, scheiß egal... Es spielt schlicht keine Rolle. Denn nur dieses Teil entscheidet über die Sicherheit... Und nichts anderes. Und genau hier legst du dein ganzes Vertrauen zwingend in den Schoß derer, die dieses Stück geschaffen haben. -> hast aber dennoch absolut Null Einfluss über die reine Sicherheit.Bei anderen Diensten ist die Möglichkeit via HTTPS Zugriff von Extern zu erlangen billigend in Kauf genommen. Nur beim WebClient scheint dies nicht auf Akzeptanz zu treffen. Also immer raus mit den Argumenten
"öffentlicher Zugriff von überall nicht nötig. Das reicht." ist kein Argument...
So kann man es machen... Der Exchange muss dazu aber zwingend runtergefahren werden/sein!
Wenn du dir den umständlichen Zwischenschritt sparen willst, die VM erst irgendwo runterzuladen, zwischenzubunkern und dann auf dem anderen ESXi wieder hochzuladen, kannst du auch den VMware Converter nehmen...
Wichtig dabei ist aber, das du möglichst die orginal VMX Datei vom Quellsystem mit dem von dir genannten Weg runter lädst und dann die auf dem Zielsystem überschreibst. Denn dort stehen diverse IDs, MAC Adressen usw. fix verankert. Der Converter selbst erzeugt beim Convertieren aber neue -> was unter Umständen problematisch ist.
Vorteil liegt klar auf der Hand, du sparst dir den Zwischenschritt des Runterladens -> denn der Converter zieht die Daten von der Quelle runter, schiebt sie in nen kleinen Cache und bringt die danach fast Live auf das Zielsystem -> Zeiteinsparung knapp die Hälfte für das reine Datenübertragen. + die Arbeit, die VMX Datei auf dem Ziel zu überschreiben und diese dann überschriebene VMX neu im Inventary registrieren...
Jupp... Im zweifel verschieben... Denn bei Kopieren werden neue IDs erzeugt -> was gegen den Baum gehen kann.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
In deinem Fall solltest du auf keinen Fall kopiert auswählen!
LichtiF
Enthusiast
Du hast es gut ich bin schon ca 15 Jahre externer Dienstleistungssklave in einem Ministerium und wir haben bis heute noch keinen VPN Zugang bekommen und machen 24/7 Bereitschaft für die lieben Polizisten die da im Schichtdienst sitzen.
Das heißt ich fahre immer 65KM wenn die anrufen das was nicht geht an den Servern
---------- Post added at 16:21 ---------- Previous post was at 16:15 ----------
bitte verschieben benutzen wie schon geschrieben wurde.
Du würdest das vCenter WebGUI von aussen direkt ohne VPN erreichbar machen?
Aber nicht in einer produktiven Umgebung, oder?
Es ist HTTPS
Bei uns läuft zwar aktuell nicht die produktive Umgebung nach public, meine Testumgebung hatte ich aber von Zuhause aus erreichbar...
Aktuell habe ich aber nicht die Zeit, das ganze mal über unseren TMG zu schieben und zu testen, ob das überhaupt lüppt
Ich hab absolut keine Ahnung, was du hier diskutierst. Ich komme mir vor wie mit nem Alzheimer-Patienten. Ich bin dann mal raus.
Edit: Schreib am besten irgendwo dazu, für welche Firma du arbeitest, nicht dass da zufällig einer Kunde wird. So eine Arbeitsweise fällt für mich unter Fahrlässigkeit.
Zuletzt bearbeitet:
Erklär mir doch bitte, wo ich den WebClient ohne jegliche Schutzmaßnahmen direkt public im INet verfügbar machen will... Zeig mir das bitte. Ich find den Punkt nicht.
Ich hab ehrlich gesagt keinen blassen Schimmer, was du mir hier versuchst einzureden. Aber ich weis denke ich genau, was ich wo schrieb. Ließ die Texte und versteh den Inhalt. OHNE irgendwelchen Quatsch dazuzuinterpretieren, der nicht Gespräch ist/war!
Thema Alzheimer Patient, das gebe ich dir gern zurück... Scheinbar muss aber schon so schlimm sein, das wärend des schreibens eines einzigen Beitrags, wo die Texte sogar noch zitiert werden, schon aussetzt mit der Erinnerung. Denn unten scheinst die Erinnerung an die oben gequoteten Texte schon verflogen
Ich hab ehrlich gesagt keinen blassen Schimmer, was du mir hier versuchst einzureden. Aber ich weis denke ich genau, was ich wo schrieb. Ließ die Texte und versteh den Inhalt. OHNE irgendwelchen Quatsch dazuzuinterpretieren, der nicht Gespräch ist/war!
Thema Alzheimer Patient, das gebe ich dir gern zurück... Scheinbar muss aber schon so schlimm sein, das wärend des schreibens eines einzigen Beitrags, wo die Texte sogar noch zitiert werden, schon aussetzt mit der Erinnerung. Denn unten scheinst die Erinnerung an die oben gequoteten Texte schon verflogen
Zuletzt bearbeitet:
CeeS
Enthusiast
Kann mir einer sagen, ob ein MS-FailoverCluster bzw. ein RDM mit einem SAS SAN (HP P2000) funktioniert UND Supported ist? Auf Vmware seite muss man wohl unter den advanced configs einen haken setzen bzw. rausnehmen, weil das SAS SAN nicht als shared Storage erkannt wird. Aber ich finde auf Seiten MS nur Angaben zu FC SANs für einen Cluster?!
Ja, die Off-Time werde ich in Kauf nehmen. Wichtig ist, dass der Server nach dem Umzug einwandfrei funktioniert. Der Exhange hat halt knapp 900GB thick-provisioned. Das dauert dann doch schon etwas
Den Converter würde ich da jetzt eher meiden.
Aber danke für den Tipp!
Anbei ein Screenshot aus dem vSphere Client zur Speichernutzung der Exchange-VM. Der Datastore auf dem Zielhost hat total 930GB. Das sollte dann grad so passen. Ist das problematisch wenn der Datastore an der Kapazitätsgrenze läuft?
VG
Anhänge
Zuletzt bearbeitet:
Falls du mal einen Snapshot machst kann es halt sein das dir der Datastore voll läuft und die VMs die in diesem Datastore liegen stehen bleiben.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Wobei man ernsthafterweise bei einer Exchange-VM keinen Snapshot macht, oder? Also ich mein wenn du nicht vorher alle Dienste gestoppt hast kannst du mit dem Snapshot nachher eh nichts mehr machen ohne weiteres oder evtl. Datenverlust...
CeeS
Enthusiast
Kann Exchange etwas kein MS-VSS?! oO
Oder verhällt es sich dabei ähnlich wie beim Active Directory?
Oder verhällt es sich dabei ähnlich wie beim Active Directory?
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Naja - du Snapst jetzt mit laufendem Exchange und gehst in 3 Stunden zurück. Dann würde ja auch die Datenbank zurückgerollt werden, dann musst du dafür sorgen, dass du keine mails bekommst, niemand was macht auf seinen Datenbanken etc... - also kannste das ding am besten direkt ausmachen.
CeeS
Enthusiast
Ja das ist ja absolut klar, das Problem ist das gleiche wie wenn ich ein Backup von vor drei Stunden zurückspiele. Hörste sich nur so an, als ob Exchange nicht VSS fähig wäre und die Datenbanken dann nicht konsistens oder vermutlich defekt.
Zgurgar meinte aber wohl auch nicht die Exchange Maschine sondern andere VMs auf dem Host
Zgurgar meinte aber wohl auch nicht die Exchange Maschine sondern andere VMs auf dem Host